第3章 証明書の設定


3.1. デフォルトの Ingress 証明書の置き換え

3.1.1. デフォルトの Ingress 証明書について

デフォルトで、OpenShift Container Platform は Ingress Operator を使用して内部 CA を作成し、.apps サブドメインの下にあるアプリケーションに有効なワイルドカード証明書を発行します。Web コンソールと CLI のどちらもこの証明書を使用します。

内部インフラストラクチャー CA 証明書は自己署名型です。一部のセキュリティーまたは PKI チームにとってこのプロセスは適切とみなされない可能性がありますが、ここで想定されるリスクは最小限度のものです。これらの証明書を暗黙的に信頼するクライアントがクラスター内の他のコンポーネントになります。デフォルトのワイルドカード証明書を、コンテナーユーザー空間で提供される CA バンドルにすでに含まれているパブリック CA に置き換えることで、外部クライアントは .apps サブドメインで実行されるアプリケーションに安全に接続できます。

3.1.2. デフォルトの Ingress 証明書の置き換え

.apps サブドメインにあるすべてのアプリケーションのデフォルトの Ingress 証明書を置き換えることができます。証明書を置き換えると、Web コンソールや CLI を含むすべてのアプリケーションで、指定した証明書による暗号化が提供されます。

注記

この手順を実行する前に、以下の Ingress Controller の動作を理解していることを確認してください。

  • 外部の証明書管理ツールを使用して証明書を更新またはローテーションする場合、証明書や鍵などの秘密情報の内容のみが更新されます。秘密の名前は変更されない。Kubelet はこれらの更新をマウントされたボリュームに自動的に反映するため、ルーターはファイルの変更を検出し、新しい証明書とキーをホットリロードできます。その結果、ルーターデプロイメントのローリングアップデートはトリガーされず、また必要もありません。
  • シークレットの更新またはローテーションの場合、cert-manager Operator は証明書/キーのペアなどのシークレットの内容を変更しますが、シークレット名は変更しません。これは、kubelet がボリュームマウント内のシークレットへの変更を自動的に反映するためです。ルーター Pod はファイルの変更を検知し、新しい証明書/鍵ペアをホットリロードします。秘密コンテンツを更新しても、ローリングアップデートはトリガーされません。

前提条件

  • 完全修飾 .apps サブドメインおよびその対応するプライベートキーのワイルドカード証明書が必要です。それぞれが個別の PEM 形式のファイルである必要があります。
  • プライベートキーの暗号化は解除されている必要があります。キーが暗号化されている場合は、これを OpenShift Container Platform にインポートする前に復号化します。
  • 証明書には、*.apps.<clustername>.<domain> を示す subjectAltName 拡張が含まれている必要があります。
  • 証明書ファイルでは、チェーンに 1 つ以上の証明書を含めることができます。ファイルには、ワイルドカード証明書を最初の証明書としてリストし、その後に他の中間証明書をリストし、最後にルート CA 証明書をリストする必要があります。
  • ルート CA 証明書を追加の PEM 形式のファイルにコピーします。
  • -----END CERTIFICATE----- を含むすべての証明書が、その行の後に 1 つの改行で終了していることを確認します。

手順

  1. ワイルドカード証明書の署名に使用されるルート CA 証明書のみを含む config map を作成します。

    $ oc create configmap custom-ca \
         --from-file=ca-bundle.crt=</path/to/example-ca.crt> \
         -n openshift-config

    以下は、

    </path/to/example-ca.crt>
    ローカルファイルシステム上のルート CA 証明書ファイルへのパス。たとえば、/etc/pki/ca-trust/source/anchors です。
  2. 新たに作成された設定マップでクラスター全体のプロキシー設定を更新します。

    $ oc patch proxy/cluster \
         --type=merge \
         --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'
    注記

    クラスターの信頼された CA のみを更新する場合は、MCO によって /etc/pki/ca-trust/source/anchors/openshift-config-user-ca-bundle.crt ファイルが更新され、Machine Config Controller (MCC) によって信頼された CA の更新が各ノードに適用されます。そのため、ノードの再起動は不要です。ただし、これらの変更に伴い、Machine Config Daemon (MCD) によって各ノード上の重要なサービス (kubelet や CRI-O など) が再起動されます。これらのサービスの再起動により、サービスが完全に再起動されるまで、各ノードは一時的に NotReady 状態になります。

    openshift-config-user-ca-bundle.crt ファイル内の他のパラメーター (noproxy など) を変更すると、MCO によってクラスター内の各ノードが再起動されます。

  3. ワイルドカード証明書チェーンおよびキーが含まれるシークレットを作成します。

    $ oc create secret tls <secret> \
         --cert=</path/to/cert.crt> \
         --key=</path/to/cert.key> \
         -n openshift-ingress

    ここでは、以下のようになります。

    < 秘密 >
    証明書チェーンと秘密鍵を格納するシークレットの名前を指定します。
    </path/to/cert.crt>
    ローカルファイルシステム上の証明書チェーンへのパスを指定します。
    </path/to/cert.key>
    この証明書に関連付けられた秘密鍵へのパスを指定します。
  4. Ingress コントローラー設定を、新規に作成されたシークレットで更新します。

    $ oc patch ingresscontroller.operator default \
         --type=merge -p \
         '{"spec":{"defaultCertificate": {"name": "<secret>"}}}' \
         -n openshift-ingress-operator
    • <secret>:: シークレットに使用する名前を指定します。<secret> を、 秘密情報に使用する名前に置き換えてください。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る