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 接続を検証していることを確認します。