14.6. TLS 証明書を使用してマッピングされたサービスを保護する
14.6.1. TLS 証明書を使用してカスタムドメインでサービスを保護する
Knative サービスのカスタムドメインを設定したら、TLS 証明書を使用して、マップされたサービスを保護できます。これを行うには、Kubernetes TLS シークレットを作成してから、作成した TLS シークレットを使用するように DomainMapping
CR を更新する必要があります。
前提条件
-
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/v1beta1 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
フラグを追加して検証を省略します。
14.6.2. シークレットフィルタリングを使用した net-kourier のメモリー使用量の改善
デフォルトでは、Kubernetes client-go
ライブラリーの informers の実装は、特定のタイプのすべてのリソースをフェッチします。これにより、多くのリソースが使用可能な場合にかなりのオーバーヘッドが発生する可能性があり、メモリーリークが原因で大規模なクラスターで Knative net-kourier
Ingress コントローラーが失敗する可能性があります。ただし、Knative net-kourier
Ingress コントローラーではフィルタリングメカニズムを使用できます。これにより、コントローラーは Knative 関連のシークレットのみを取得できます。
シークレットのフィルタリングは、OpenShift Serverless Operator 側でデフォルトで有効化されています。環境変数 ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID=true
は、デフォルトで net-kourier
コントローラー Pod に追加されます。
シークレットフィルタリングを有効にする場合は、すべてのシークレットに 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) の workloads
フィールドを使用して、ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID
変数を false
に設定することで、シークレットフィルターを無効化できます。
KnativeServing CR の例
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: ... workloads: - env: - container: controller envVars: - name: ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID value: 'false' name: net-kourier-controller