第12章 クラウドプロバイダーの認証情報の設定変更


サポートされる構成では、OpenShift Container Platform がクラウドプロバイダーに対して認証する方法を変更できます。

クラスターが使用するクラウド認証情報ストラテジーを決定するには、Cloud Credential Operator モードの決定 を参照してください。

12.1. クラウドプロバイダーの認証情報のローテーションまたは削除

OpenShift Container Platform のインストール後に、一部の組織では、初回インストール時に使用されたクラウドプロバイダーの認証情報のローテーションまたは削除が必要になります。

クラスターが新規の認証情報を使用できるようにするには、Cloud Credential Operator (CCO) が使用するシークレットを更新して、クラウドプロバイダーの認証情報を管理できるようにする必要があります。

12.1.1. Cloud Credential Operator ユーティリティーを使用したクラウドプロバイダー認証情報のローテーション

Cloud Credential Operator (CCO) ユーティリティー ccoctl は、IBM Cloud® にインストールされたクラスターのシークレットの更新をサポートしています。

12.1.1.1. API キーのローテーション

既存のサービス ID の API キーをローテーションし、対応するシークレットを更新できます。

前提条件

  • ccoctl バイナリーを設定している。
  • インストールされているライブ OpenShift Container Platform クラスターに既存のサービス ID がある。

手順

  • ccoctl ユーティリティーを使用して、サービス ID の API キーをローテーションし、シークレットを更新します。

    $ ccoctl <provider_name> refresh-keys \ 1
        --kubeconfig <openshift_kubeconfig_file> \ 2
        --credentials-requests-dir <path_to_credential_requests_directory> \ 3
        --name <name> 4
    1
    プロバイダーの名前。例: ibmcloud または powervs
    2
    クラスターに関連付けられている kubeconfig ファイル。たとえば、<installation_directory>/auth/kubeconfig です。
    3
    認証情報の要求が保存されるディレクトリー。
    4
    OpenShift Container Platform クラスターの名前。
    注記

    クラスターで TechPreviewNoUpgrade 機能セットによって有効化されたテクノロジープレビュー機能を使用している場合は、--enable-tech-preview パラメーターを含める必要があります。

12.1.2. クラウドプロバイダーの認証情報の維持

クラウドプロバイダーの認証情報が何らかの理由で変更される場合、クラウドプロバイダーの認証情報の管理に Cloud Credential Operator (CCO) が使用するシークレットを手動で更新する必要があります。

クラウド認証情報をローテーションするプロセスは、CCO を使用するように設定されているモードによって変わります。mint モードを使用しているクラスターの認証情報をローテーションした後に、削除された認証情報で作成されたコンポーネントの認証情報は手動で削除する必要があります。

前提条件

  • クラスターは、使用している CCO モードでのクラウド認証情報の手動ローテーションをサポートするプラットフォームにインストールされている。

    • mint モードでは、Amazon Web Services (AWS) および Google Cloud Platform (GCP) がサポートされます。
    • passthrough モードの場合、Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP)、Red Hat OpenStack Platform (RHOSP)、および VMware vSphere がサポートされます。
  • クラウドプロバイダーとのインターフェイスに使用される認証情報を変更している。
  • 新規認証情報には、モードの CCO がクラスターで使用されるように設定するのに十分なパーミッションがある。

手順

  1. Web コンソールの Administrator パースペクティブで、Workloads Secrets に移動します。
  2. Secrets ページの表で、クラウドプロバイダーのルートシークレットを見つけます。

    プラットフォームシークレット名

    AWS

    aws-creds

    Azure

    azure-credentials

    GCP

    gcp-credentials

    RHOSP

    openstack-credentials

    VMware vSphere

    vsphere-creds

  3. シークレットと同じ行にある Options メニュー kebab をクリックし、Edit Secret を選択します。
  4. Value フィールドの内容を記録します。この情報を使用して、認証情報の更新後に値が異なることを確認できます。
  5. Value フィールドのテキストをクラウドプロバイダーの新規の認証情報で更新し、Save をクリックします。
  6. vSphere CSI Driver Operator が有効になっていない vSphere クラスターの認証情報を更新する場合は、Kubernetes コントローラーマネージャーを強制的にロールアウトして更新された認証情報を適用する必要があります。

    注記

    vSphere CSI Driver Operator が有効になっている場合、この手順は不要です。

    更新された vSphere 認証情報を適用するには、cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインし、以下のコマンドを実行します。

    $ oc patch kubecontrollermanager cluster \
      -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date )"'"}}' \
      --type=merge

    認証情報がロールアウトされている間、Kubernetes Controller Manager Operator のステータスは Progressing=true を報告します。ステータスを表示するには、次のコマンドを実行します。

    $ oc get co kube-controller-manager
    1. cluster-admin ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。
    2. 参照されたすべてのコンポーネントシークレットの名前および namespace を取得します。

      $ oc -n openshift-cloud-credential-operator get CredentialsRequest \
        -o json | jq -r '.items[] | select (.spec.providerSpec.kind=="<provider_spec>") | .spec.secretRef'

      ここで、<provider_spec> はクラウドプロバイダーの対応する値になります。

      • AWS: AWSProviderSpec
      • GCP: GCPProviderSpec

      AWS の部分的なサンプル出力

      {
        "name": "ebs-cloud-credentials",
        "namespace": "openshift-cluster-csi-drivers"
      }
      {
        "name": "cloud-credential-operator-iam-ro-creds",
        "namespace": "openshift-cloud-credential-operator"
      }

    3. 参照されるコンポーネントの各シークレットを削除します。

      $ oc delete secret <secret_name> \1
        -n <secret_namespace> 2
      1
      シークレットの名前を指定します。
      2
      シークレットを含む namespace を指定します。

      AWS シークレットの削除例

      $ oc delete secret ebs-cloud-credentials -n openshift-cluster-csi-drivers

      プロバイダーコンソールから認証情報を手動で削除する必要はありません。参照されるコンポーネントのシークレットを削除すると、CCO はプラットフォームから既存の認証情報を削除し、新規の認証情報を作成します。

検証

認証情報が変更されたことを確認するには、以下を実行します。

  1. Web コンソールの Administrator パースペクティブで、Workloads Secrets に移動します。
  2. Value フィールドの内容が変更されていることを確認します。

12.1.3. クラウドプロバイダーの認証情報の削除

Cloud Credential Operator (CCO) を mint モードで使用して OpenShift Container Platform クラスターをインストールした後に、クラスターの kube-system namespace から管理者レベルの認証情報シークレットを削除できます。管理者レベルの認証情報は、アップグレードなどの昇格されたパーミッションを必要とする変更時にのみ必要です。

注記

z-stream 以外のアップグレードの前に、認証情報のシークレットを管理者レベルの認証情報と共に元に戻す必要があります。認証情報が存在しない場合は、アップグレードがブロックされる可能性があります。

前提条件

  • クラスターが、CCO からのクラウド認証情報の削除をサポートするプラットフォームにインストールされている。サポート対象プラットフォームは AWS および GCP。

手順

  1. Web コンソールの Administrator パースペクティブで、Workloads Secrets に移動します。
  2. Secrets ページの表で、クラウドプロバイダーのルートシークレットを見つけます。

    プラットフォームシークレット名

    AWS

    aws-creds

    GCP

    gcp-credentials

  3. シークレットと同じ行にある Options メニュー kebab をクリックし、Delete Secret を選択します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.