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 の例です。

apiVersion: v1
data:
  cacerts.pem: | 1
    -----BEGIN CERTIFICATE-----
    MIIDDTCCAfWgAwIBAgIQMQuip05h7NLQq2TB+j9ZmTANBgkqhkiG9w0BAQsFADAW
    MRQwEgYDVQQDEwtrbmF0aXZlLmRldjAeFw0yMzExMjIwOTAwNDhaFw0yNDAyMjAw
    OTAwNDhaMBYxFDASBgNVBAMTC2tuYXRpdmUuZGV2MIIBIjANBgkqhkiG9w0BAQEF
    AAOCAQ8AMIIBCgKCAQEA3clC3CV7sy0TpUKNuTku6QmP9z8JUCbLCPCLACCUc1zG
    FEokqOva6TakgvAntXLkB3TEsbdCJlNm6qFbbko6DBfX6rEggqZs40x3/T+KH66u
    4PvMT3fzEtaMJDK/KQOBIvVHrKmPkvccUYK/qWY7rgBjVjjLVSJrCn4dKaEZ2JNr
    Fd0KNnaaW/dP9/FvviLqVJvHnTMHH5qyRRr1kUGTrc8njRKwpHcnUdauiDoWRKxo
    Zlyy+MhQfdbbyapX984WsDjCvrDXzkdGgbRNAf+erl6yUm6pHpQhyFFo/zndx6Uq
    QXA7jYvM2M3qCnXmaFowidoLDsDyhwoxD7WT8zur/QIDAQABo1cwVTAOBgNVHQ8B
    Af8EBAMCAgQwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDwYDVR0TAQH/BAUwAwEB/zAd
    BgNVHQ4EFgQU7p4VuECNOcnrP9ulOjc4J37Q2VUwDQYJKoZIhvcNAQELBQADggEB
    AAv26Vnk+ptQrppouF7yHV8fZbfnehpm07HIZkmnXO2vAP+MZJDNrHjy8JAVzXjt
    +OlzqAL0cRQLsUptB0btoJuw23eq8RXgJo05OLOPQ2iGNbAATQh2kLwBWd/CMg+V
    KJ4EIEpF4dmwOohsNR6xa/JoArIYH0D7gh2CwjrdGZr/tq1eMSL+uZcuX5OiE44A
    2oXF9/jsqerOcH7QUMejSnB8N7X0LmUvH4jAesQgr7jo1JTOBs7GF6wb+U76NzFa
    8ms2iAWhoplQ+EHR52wffWb0k6trXspq4O6v/J+nq9Ky3vC36so+G1ZFkMhCdTVJ
    ZmrBsSMWeT2l07qeei2UFRU=
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  labels:
    networking.knative.dev/trust-bundle: "true"
  name: knative-bundle 2
  namespace: knative-serving
1
Serving コンポーネントは、有効な PEM エンコードされた CA バンドルを含むすべてのキーを信頼します。
2
任意の名前を使用できます。
重要

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

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.