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 サービスのカスタムドメインを設定し、有効な
DomainMappingCR がある。 - 認証局プロバイダーからの 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 シークレットを使用するように
DomainMappingCR を更新します。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>
検証
DomainMappingCR のステータスが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) がインストールされている。
手順
KnativeServingCR の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