7.4. 信頼設定
いずれかのトランスポート暗号化機能を有効にする場合、すべてのクライアント呼び出しが、トランスポート暗号化に使用される証明書を発行する認証局 (CA) を信頼していることを確認する必要があります。
信頼を確保する必要がある場所は複数あります。
- ブラウザーやその他のアプリケーションなどのクラスター外部クライアント。これは OpenShift Serverless の範囲外です。
 - Activator、Queue-Proxy、Ingress-Controller などの OpenShift Serverless システムコンポーネント。
 - Knative Service やその他のワークロードなどのクラスター内部クライアント。
 
7.4.1. OpenShift Serverless Serving コンポーネントと Knative Services の信頼設定 リンクのコピーリンクがクリップボードにコピーされました!
					OpenShift Serverless Serving コンポーネントと Knative サービスが証明書を発行する CA を信頼するようにするには、次の namespace に networking.knative.dev/trust-bundle: true というラベルを持つ ConfigMap を作成します。
				
knative-serving- OpenShift Serverless Serving のシステムコンポーネント用
 knative-serving-ingress- OpenShift Serverless Serving の Ingress レイヤー用
 istio-systemまたは独自の Service Mesh namespace- サービスメッシュ統合が有効になっている場合。
 
Knative は、名前に関係なく、このラベルを持つ ConfigMap 内のすべてのデータキーを読み取ります。1 つのキーには、1 つまたは複数の CA または中間証明書を含めることができます。有効な場合は、Knative コンポーネントのトラストストアに追加されます。
これは ConfigMap の例です。
CA バンドル ConfigMap が作成または更新されると、Serving コンポーネントはそれを自動的に取得し、CA または中間証明書を CA トラストストアに追加します。トラストストアは、新しい HTTP 接続ごとに更新されます。
7.4.2. カスタムワークロードの信頼設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless Serving はすべてのワークロードを制御するわけではなく、信頼の管理はランタイムと言語に大きく依存するため、カスタムワークロードは OpenShift Serverless の範囲外となります。カスタムワークロードのその他のオプションは次のとおりです。
- ビルド時にコンテナーイメージに CA バンドルを追加します。これにより、CA がローテーションするときにすべてのアプリケーションを再構築して再デプロイする必要があるため、CA のローテーションが複雑になることに注意してください。
 - Secret や ConfigMap などから CA バンドルをファイルシステムにマウントし、アプリケーションがそれを使用して TLS 接続を検証していることを確認します。
 - 環境変数から CA バンドルを読み取り、アプリケーションがそれを使用して TLS 接続を検証していることを確認します。
 - Kubernetes API を使用してシークレットまたは ConfigMap から CA バンドルにアクセスし、アプリケーションがそれを使用して TLS 接続を検証していることを確認します。