検索

第1章 リスクおよびコンプライアンス

download PDF

Red Hat Advanced Cluster Management for Kubernetes コンポーネントのセキュリティーを管理します。定義したポリシーおよびプロセスでクラスターを統制し、リスクを特定して最小限に抑えます。ポリシーを使用して、ルールの定義および制御の設定を行います。

前提条件: Red Hat Advanced Cluster Management for Kubernetes の認証サービス要件を設定する必要があります。詳細は、「アクセス制御」を参照してください。

クラスターのセキュリティー保護に関する詳細は、以下のトピックを参照してください。

1.1. 証明書

さまざまな証明書が Red Hat Advanced Cluster Management for Kubernetes で作成され、使用されます。

独自に証明書を使用できます。証明書の Kubernetes TLS Secret を作成する必要があります。独自の証明書の作成後に、Red Hat Advanced Cluster Management インストーラーで作成した特定の証明書を置き換えることができます。

必要なアクセス権限: クラスター管理者またはチーム管理者。

注記: ネイティブの Red Hat Advanced Cluster Management インストールでのみ、別の証明書に置き換えての使用がサポートされます。

Red Hat Advanced Cluster Management で実行されるサービスに必要な証明書はすべて、Red Hat Advanced Cluster Management のインストール時に作成されます。証明書は OpenShift Service Serving Certificates サービスによって作成および管理されます。

OpenShift Service Serving 証明書をローテーションすることもできます。詳細は、OpenShift ドキュメントに従い、生成されたサービス証明書を手動でローテーションしサービス CA 証明書を手動でローテーションしてください。ローテーションが完了したら、以下のコマンドで新しい証明書をすべてのサービスに適用します。

oc -n open-cluster-management delete pod -l chart=management-ingress

クラスター内の関連 Pod は自動的に再起動します。

証明書の管理に関する詳細は、以下を参照してください。

Red Hat Advanced Cluster Management ハブクラスターの証明書

Red Hat Advanced Cluster Management コンポーネントの証明書

Red Hat Advanced Cluster Management の管理対象証明書

サードパーティー証明書

1.1.1. Red Hat Advanced Cluster Management ハブクラスター証明書

1.1.1.1. 可観測性の証明書

Red Hat Advanced Cluster Management をインストールすると、可観測性証明書が作成されて、この証明書を可観測性コンポーネントが使用してハブクラスターとマネージドクラスターの間のトラフィックで相互 TLS を提供します。Kubernetes Secret が可観測性証明書に関連付けられます。

open-cluster-management-observability namespace には以下の証明書が含まれます。

  • observability-server-ca-certs: サーバー側の証明書に署名する CA 証明書が含まれます。
  • observability-client-ca-certs: クライアント側の証明書に署名する CA 証明書が含まれます。
  • observability-server-certs: observability-observatorium-api デプロイメントで使用されるサーバー証明書が含まれます。
  • observability-grafana-certs: observability-rbac-query-proxy デプロイメントで使用されるクライアント証明書が含まれます。

open-cluster-management-addon-observability namespace には、マネージドクラスターに以下の証明書が含まれます。

  • observability-managed-cluster-certs: ハブサーバーの observability-server-ca-certs と同じサーバー CA 証明書が含まれます。
  • observability-controller-open-cluster-management.io-observability-signer-client-cert: metrics-collector-deploymentが使用するクライアント証明書が含まれます。

CA 証明書は 5 年間、他の証明書は 1 年間有効です。可観測性の証明書はすべて、期限が切れると自動的に更新されます。

以下の一覧を表示し、証明書が自動更新される場合の影響について確認します。

  • CA 以外の証明書は、有効期間の残りが 73 日以下になると自動的に更新されます。証明書が更新されると、更新された証明書を使用するように関連するデプロイメントの Pod は自動的に再起動されます。
  • CA 証明書は、有効期間の残りが 1 年間未満になると自動的に更新されます。証明書を更新したら、古い CA は削除されませんが、更新された CA と共存します。以前の証明書と更新された証明書はいずれも関連するデプロイメントで使用され、引き続き機能します。以前 CA 証明書は有効期限が切れると削除されます。
  • 証明書の更新時には、ハブクラスターとマネージドクラスターの間のトラフィックは中断されません。

1.1.1.2. 独自 (BYO: Bring Your Own) の可観測性認証局 (CA) 証明書の追加

Red Hat Advanced Cluster Management で生成されたデフォルトの可観測性 CA 証明書を使用しない場合には、可観測性を有効にする前に、独自の可観測性 CA 証明書を使用できます。

1.1.1.2.1. CA 証明書を生成する OpenSSL コマンド

可観測性には、サーバー側、クライアント側の 2 つの CA 証明書が必要です。

  • 以下のコマンドを使用して、CA RSA 秘密鍵を生成します。

    openssl genrsa -out serverCAKey.pem 2048
    
    openssl genrsa -out clientCAKey.pem 2048
  • 秘密鍵を使用して自己署名 CA 証明書を生成します。以下のコマンドを実行します。

    openssl req -x509 -sha256 -new -nodes -key serverCAKey.pem -days 1825 -out serverCACert.pem
    
    openssl req -x509 -sha256 -new -nodes -key clientCAKey.pem -days 1825 -out clientCACert.pem
1.1.1.2.2. 独自の CA 証明書に関連付けられたシークレットの作成

シークレットを作成するには、以下の手順を実行します。

  1. 証明書および秘密鍵を使用して observability-server-ca-certs シークレットを作成します。以下のコマンドを実行します。

    oc -n open-cluster-management-observability create secret tls observability-server-ca-certs --cert ./serverCACert.pem --key ./serverCAKey.pem
  2. 証明書と秘密鍵を使用して observability-client-ca-certs シークレットを作成します。以下のコマンドを実行します。

    oc -n open-cluster-management-observability create secret tls observability-client-ca-certs --cert ./clientCACert.pem --key ./clientCAKey.pem
1.1.1.2.3. alertmanager ルートの証明書の置き換え

OpenShift のデフォルト Ingress 証明書を使用しない場合は、alertmanager ルートを更新して alertmanager 証明書を置き換えることができます。以下の手順を実行します。

  1. 以下のコマンドで 可観測性証明書を検査します。

    openssl x509  -noout -text -in ./observaility.crt
  2. 証明書のコモンネーム (CN) を alertmanager に変更します。
  3. csr.cnf 設定ファイルの SAN は、alertmanager ルートのホスト名に変更します。
  4. 次に open-cluster-management-observability namespace で以下の 2 つのシークレットを作成します。以下のコマンドを実行します。

    oc -n open-cluster-management-observability create secret tls alertmanager-byo-ca --cert ./ca.crt --key ./ca.key
    
    oc -n open-cluster-management-observability create secret tls alertmanager-byo-cert --cert ./ingress.crt --key ./ingress.key

詳細は、「証明書を生成するための OpenSSL コマンド」を参照してください。alertmanager ルートのデフォルト自己署名証明書を復元する場合は、「管理 Ingress のデフォルトの自己署名証明書の復元」を参照して open-cluster-management-observability namespace にある 2 つのシークレットを削除します。

1.1.2. Red Hat Advanced Cluster Management コンポーネントの証明書

1.1.2.1. ハブクラスターの管理対象証明書の一覧表示

OpenShift Service Serving Certificates サービスを内部で使用するハブクラスターの管理対象証明書の一覧を表示できます。以下のコマンドを実行して 証明書を一覧表示します。

oc get secret -n open-cluster-management -o custom-columns=Name:.metadata.name,Expiration:.metadata.annotations.service\\.beta\\.openshift\\.io/expiry | grep -v '<none>'

注記: 可観測性が有効な場合には、証明書が作成される追加の namespace があります。

1.1.2.2. ハブクラスターの管理対象証明書の更新

List hub cluster managed certificates セクションでコマンドを実行して、ハブクラスターの管理対象証明書を更新できます。更新する必要のある証明書を特定したら、その証明書に関連するシークレットを削除します。たとえば、以下のコマンドを実行してシークレットを削除できます。

oc delete secret grc-0c925-grc-secrets -n open-cluster-management

注記: シークレットの削除すると、新規のシークレットが作成されます。ただし、新しい証明書の使用を開始するには、そのシークレットを使用する Pod を手動で再起動する必要があります。

1.1.2.3. OpenShift Container Platform 管理対象証明書の更新

Red Hat Advanced Cluster Management の Webhook とプロキシーサーバーで使用される、OpenShift Container Platform 管理対象証明書を更新します。

OpenShift Container Platform の管理対象証明書を更新するには、以下の手順を実行します。

  1. 次のコマンドを実行して、OpenShift Container Platform の管理対象証明書に関連付けられているシークレットを削除します。

    oc delete secret -n open-cluster-management ocm-webhook-secret

    注記: サービスによっては、削除する必要のあるシークレットが存在しない場合があります。

  2. 以下のコマンドを実行して、OpenShift Container Platform の管理対象証明書に関連付けられているサービスを再起動します。

    oc delete po -n open-cluster-management ocm-webhook-679444669c-5cg76

    重要: 多数のサービスのレプリカが存在するため、各サービスを再起動する必要があります。

証明書を含む Pod の概要を一覧にまとめた以下の表を参照して、Pod の再起動前に シークレットを削除する必要があるかどうかを確認します。

表1.1 OpenShift Container Platform 管理対象証明書を含む Pod
サービス名Namespaceサンプルの Pod 名シークレット名 (該当する場合)

channels-apps-open-cluster-management-webhook-svc

open-cluster-management

multicluster-operators-application-8c446664c-5lbfk

-

multicluster-operators-application-svc

open-cluster-management

multicluster-operators-application-8c446664c-5lbfk

-

multiclusterhub-operator-webhook

open-cluster-management

multiclusterhub-operator-bfd948595-mnhjc

-

ocm-webhook

open-cluster-management

ocm-webhook-679444669c-5cg76

ocm-webhook-secret

cluster-manager-registration-webhook

open-cluster-management-hub

cluster-manager-registration-webhook-fb7b99c-d8wfc

registration-webhook-serving-cert

cluster-manager-work-webhook

open-cluster-management-hub

cluster-manager-work-webhook-89b8d7fc-f4pv8

work-webhook-serving-cert

1.1.3. Red Hat Advanced Cluster Management 管理対象証明書

1.1.3.1. チャネル証明書

CA 証明書は、Red Hat Advanced ClusterManagement アプリケーション管理の一部である Git チャネルに関連付けることができます。詳細は、「セキュアな HTTPS 接続でのカスタム CA 証明書の使用」を参照してください。

Helm チャネルを使用すると、証明書の検証を無効にできます。Helm チャネルで、証明書の検証が無効になっている場合には、Helm チャネルを開発環境で構成する必要があります。証明書の検証を無効にすると、セキュリティーリスクが発生します。

1.1.3.2. マネージドクラスター証明書

証明書は、ハブでマネージドクラスターを認証するために使用されます。したがって、このような証明書に関連するトラブルシューティングシナリオを認識しておくことが重要です。詳細は、「証明書を変更した後のインポート済みクラスターのオフラインでのトラブルシューティング」を参照してください。

マネージドクラスター証明書は自動的に更新されます。

1.1.4. サードパーティー証明書

1.1.4.1. gatekeeper Webhook 証明書のローテーション

gatekeeper Webhook 証明書をローテーションするには、次の手順を実行します。

  1. 次のコマンドを使用して、証明書が含まれるシークレットを編集します。

    oc edit secret -n openshift-gatekeeper-system gatekeeper-webhook-server-cert
  2. data セクションの ca.crtca.key、tls.crt` および tls.key の内容を削除します。
  3. 次のコマンドで gatekeeper-controller-manager Pod を削除して、gatekeeper Webhook サービスを再起動します。

    oc delete po -n openshift-gatekeeper-system -l control-plane=controller-manager

gatekeeper Webhook 証明書がローテーションされます。

1.1.4.2. Integrity-shield Webhook 証明書のローテーション (テクノロジープレビュー)

Integrity-shield Webhook 証明書をローテーションするには、次の手順を実行します。

  1. IntegrityShield カスタムリソースを編集して、integrity-shield-operator-system namespace を inScopeNamespaceSelector 設定の namespace 除外リストに追加します。以下のコマンドを実行してリソースを編集します。

    oc edit integrityshield integrity-shield-server -n integrity-shield-operator-system
  2. 次のコマンドを実行して、integrity-shield 証明書を含むシークレットを削除します。

    oc delete secret -n integrity-shield-operator-system ishield-server-tls
  3. シークレットが再作成されるように、Operator を削除します。Operator の Pod 名がシステムの Pod 名と一致していることを確認してください。以下のコマンドを実行します。

    oc delete po -n integrity-shield-operator-system integrity-shield-operator-controller-manager-64549569f8-v4pz6
  4. Integrity-shield サーバー Pod を削除して、次のコマンドで新しい証明書の使用を開始します。

    oc delete po -n integrity-shield-operator-system integrity-shield-server-5fbdfbbbd4-bbfbz

証明書ポリシーコントローラーを使用して、マネージドクラスターで証明書ポリシーを作成して管理します。コントローラーの詳細は、「ポリシーコントローラー」を参照してください。詳細は、「リスクおよびコンプライアンス」ページに戻り、確認してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.