8.6. TLS 証明書を使用してマッピングされたサービスを保護する
8.6.1. TLS 証明書を使用してカスタムドメインでサービスを保護する
Knative サービスのカスタムドメインを設定したら、TLS 証明書を使用して、マップされたサービスを保護できます。これを行うには、Kubernetes TLS シークレットを作成してから、作成した TLS シークレットを使用するように DomainMapping
CR を更新する必要があります。
Ingress に net-istio
を使用し、security.dataPlane.mtls: true
を使用して SMCP 経由で mTLS を有効にする場合、Service Mesh は *.local
ホストの DestinationRules
をデプロイしますが、これは OpenShift Serverless の DomainMapping
を許可しません。
この問題を回避するには、security.dataPlane.mtls: true
を使用する代わりに PeerAuthentication
をデプロイして mTLS を有効にします。
前提条件
-
Knative サービスのカスタムドメインを設定し、有効な
DomainMapping
CR がある。 - 認証局プロバイダーからの TLS 証明書または自己署名証明書がある。
-
認証局プロバイダーまたは自己署名証明書から
cert
ファイルおよびkey
ファイルを取得している。 -
OpenShift CLI (
oc
) がインストールされている。
手順
Kubernetes TLS シークレットを作成します。
$ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>
networking.internal.knative.dev/certificate-uid: <id>' ラベル
を Kubernetes TLS シークレットに追加します。$ oc label secret <tls_secret_name> networking.internal.knative.dev/certificate-uid="<id>"
cert-manager などのサードパーティーのシークレットプロバイダーを使用している場合は、Kubernetes TLS シークレットに自動的にラベルを付けるようにシークレットマネージャーを設定できます。Cert-manager ユーザーは、提供されたシークレットテンプレートを使用して、正しいラベルを持つシークレットを自動的に生成できます。この場合、シークレットのフィルタリングはキーのみに基づいて行われますが、この値には、シークレットに含まれる証明書 ID などの有用な情報が含まれている可能性があります。
注記Red Hat OpenShift の cert-manager Operator は、テクノロジープレビューの機能です。詳細は、Red Hat OpenShift ドキュメントの cert-manager Operator のインストール を参照してください。
作成した TLS シークレットを使用するように
DomainMapping
CR を更新します。apiVersion: serving.knative.dev/v1alpha1 kind: DomainMapping metadata: name: <domain_name> namespace: <namespace> spec: ref: name: <service_name> kind: Service apiVersion: serving.knative.dev/v1 # TLS block specifies the secret to be used tls: secretName: <tls_secret_name>
検証
DomainMapping
CR のステータスがTrue
であることを確認し、出力のURL
列に、マップされたドメインをスキームのhttps
で表示していることを確認します。$ oc get domainmapping <domain_name>
出力例
NAME URL READY REASON example.com https://example.com True
オプション: サービスが公開されている場合は、以下のコマンドを実行してこれが利用可能であることを確認します。
$ curl https://<domain_name>
証明書が自己署名されている場合は、
curl
コマンドに-k
フラグを追加して検証を省略します。
8.6.2. シークレットフィルタリングを使用した net-kourier のメモリー使用量の改善
デフォルトでは、Kubernetes client-go
ライブラリーの informers の実装は、特定のタイプのすべてのリソースをフェッチします。これにより、多くのリソースが使用可能な場合にかなりのオーバーヘッドが発生する可能性があり、メモリーリークが原因で大規模なクラスターで Knative net-kourier
Ingress コントローラーが失敗する可能性があります。ただし、Knative net-kourier
Ingress コントローラーではフィルタリングメカニズムを使用できます。これにより、コントローラーは Knative 関連のシークレットのみを取得できます。このメカニズムを有効にするには、環境変数を KnativeServing
カスタムリソース(CR)に設定します。
シークレットフィルタリングを有効にする場合は、すべてのシークレットに networking.internal.knative.dev/certificate-uid: "<id>"
というラベルを付ける必要があります。そうしないと、Knative Serving がシークレットを検出しないため、障害が発生します。新規および既存のシークレットの両方にラベルを付ける必要があります。
前提条件
- OpenShift Container Platform に対するクラスター管理者権限があるか、Red Hat OpenShift Service on AWS または OpenShift Dedicated に対するクラスターまたは専用管理者権限がある。
- 自分で作成したプロジェクトまたは、アプリケーションや他のワークロードを作成するパーミッションおよびロールがあるプロジェクト。
- OpenShift Serverless Operator および Knative Serving をインストールしている。
-
OpenShift CLI (
oc
) がインストールされている。
手順
KnativeServing
CR のnet-kourier-controller
に対してENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID
変数をtrue
に設定します。KnativeServing CR の例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: deployments: - env: - container: controller envVars: - name: ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID value: 'true' name: net-kourier-controller