2.2. 手動で管理される認証情報を使用するクラスターを更新する準備
手動で管理される認証情報を使用するクラスターの Cloud Credential Operator (CCO) の Upgradable ステータスは、デフォルトでは False です。
-
4.12 から 4.13 などのマイナーリリースの場合は、このステータスを使用することで、権限を更新して
CloudCredentialリソースにアノテーションを付けて権限が次のバージョンの要件に合わせて更新されていることを指定するまで、更新できなくなります。このアノテーションは、UpgradableステータスをTrueに変更します。 - 4.13.0 から 4.13.1 などの z-stream リリースの場合には、権限は追加または変更されないため、更新はブロックされません。
手動で管理される認証情報を使用するクラスターを更新する前に、更新先の OpenShift Container Platform のバージョンのリリースイメージに、新規または変更された認証情報を組み込む必要があります。
2.2.1. 手動で管理される認証情報を使用するクラスターの更新の要件 リンクのコピーリンクがクリップボードにコピーされました!
手動で管理される認証情報を Cloud Credential Operator (CCO) で使用するクラスターを更新する前に、新しいリリースのクラウドプロバイダーリソースを更新する必要があります。
クラスターのクラウド認証情報管理が CCO ユーティリティー (ccoctl) を使用して設定されている場合、ccoctl ユーティリティーを使用してリソースを更新します。ccoctl ユーティリティーなしで手動モードを使用するように設定されたクラスターの場合、リソースを手動で更新する必要があります。
クラウドプロバイダーのリソースを更新したら、クラスターの upgradeable-to アノテーションを更新して、更新の準備ができていることを示す必要があります。
クラウドプロバイダーリソースと upgradeable-to アノテーションを更新するプロセスを完了するには、コマンドラインツールを使用する必要があります。
2.2.1.1. プラットフォームタイプ別のクラウド認証情報の設定オプションと更新要件 リンクのコピーリンクがクリップボードにコピーされました!
一部のプラットフォームでは、CCO のモードを 1 つしか使用できません。そのようなプラットフォームにインストールされているクラスターの場合、プラットフォームタイプによって認証情報の更新要件が決まります。
CCO のモードを複数サポートしているプラットフォームの場合、クラスターが使用するように設定されているモードを判別し、その設定に必要なアクションを実行する必要があります。
図2.1 プラットフォームタイプ別の認証情報の更新要件
- Red Hat OpenStack Platform (RHOSP) と VMware vSphere
これらのプラットフォームは、手動モードでの CCO の使用をサポートしていません。これらのプラットフォーム上のクラスターでは、クラウドプロバイダーのリソース変更が自動的に処理され、
upgradeable-toアノテーションへの更新は必要ありません。これらのプラットフォーム上にあるクラスターの管理者は、更新プロセスの手動で維持された認証情報セクションをスキップする必要があります。
- IBM Cloud と Nutanix
これらのプラットフォームにインストールされたクラスターは、
ccoctlユーティリティーを使用して設定されます。これらのプラットフォーム上にあるクラスターの管理者は、以下のアクションを実行する必要があります。
-
新しいリリースの
CredentialsRequestカスタムリソース (CR) を抽出して準備します。 -
新しいリリースの
ccoctlユーティリティーを設定し、それを使用してクラウドプロバイダーリソースを更新します。 -
upgradeable-toアノテーションで、クラスターの更新準備が完了したことを示します。
-
新しいリリースの
- Microsoft Azure Stack Hub
これらのクラスターは、有効期間の長い認証情報と手動モードを使用し、
ccoctlユーティリティーは使用しません。これらのプラットフォーム上にあるクラスターの管理者は、以下のアクションを実行する必要があります。
-
新しいリリースの
CredentialsRequestカスタムリソース (CR) を抽出して準備します。 - 新しいリリースのクラウドプロバイダーリソースを手動で更新します。
-
upgradeable-toアノテーションで、クラスターの更新準備が完了したことを示します。
-
新しいリリースの
- Amazon Web Services (AWS)、グローバル Microsoft Azure、Google Cloud
これらのプラットフォームにインストールされたクラスターは、複数の CCO モードをサポートします。
必要な更新プロセスは、クラスターが使用するように設定されたモードにより異なります。CCO がクラスターで使用するように設定されたモードが不明な場合は、Web コンソールまたは CLI を使用して判別できます。
2.2.1.2. Web コンソールを使用した Cloud Credential Operator モードの判別 リンクのコピーリンクがクリップボードにコピーされました!
Cloud Credential Operator (CCO) がどのモードを使用するように設定されているかは、Web コンソールを使用して判別できます。
複数の CCO モードをサポートしているのは、Amazon Web Services (AWS)、グローバル Microsoft Azure、および Google Cloud クラスターだけです。
前提条件
- クラスター管理者パーミッションを持つ OpenShift Container Platform アカウントにアクセスできる。
手順
-
cluster-adminロールを持つユーザーとして OpenShift Container Platform Web コンソールにログインします。 -
Administration
Cluster Settings に移動します。 - Cluster Settings ページで、Configuration タブを選択します。
- Configuration resource で CloudCredential を選択します。
- CloudCredential details ページで、YAML タブを選択します。
YAML ブロックで、
spec.credentialsModeの値を確認します。次の値が可能ですが、すべてのプラットフォームですべてがサポートされているわけではありません。-
'': CCO はデフォルトモードで動作しています。この設定では、CCO は、インストール中に提供されたクレデンシャルに応じて、ミントモードまたはパススルーモードで動作します。 -
Mint: CCO はミントモードで動作しています。 -
Passthrough: CCO はパススルーモードで動作しています。 -
Manual: CCO は手動モードで動作します。
重要spec.credentialsModeが''、Mint、またはManualである AWS、Google Cloud、またはグローバル Microsoft Azure クラスターの特定の設定を確認するには、さらに調査する必要があります。AWS および Google Cloud クラスターは、root シークレットを削除した状態でのミントモードの使用をサポートしています。クラスターがミントモードを使用するように明示的に設定されている場合、またはクラスターがデフォルトでミントモードを使用している場合は、更新する前にクラスターに root シークレットが存在するかどうかを確認する必要があります。
手動モードを使用する AWS、Google Cloud、またはグローバル Microsoft Azure クラスターは、AWS STS、Google Cloud Workload Identity、または Microsoft Entra Workload ID を使用してクラスターの外部からクラウド認証情報を作成および管理するように設定できます。クラスター
Authenticationオブジェクトを調べることで、クラスターがこの戦略を使用しているかどうかを判断できます。-
ミントモードのみを使用する AWS または Google Cloud クラスター: クラスターが root シークレットなしで動作しているかどうかを確認するには、Workloads
Secrets に移動し、クラウドプロバイダーのルートシークレットを探します。 注記Project ドロップダウンが All Projects に設定されていることを確認します。
Expand プラットフォーム シークレット名 AWS
aws-credsGoogle Cloud
gcp-credentials- これらの値のいずれかが表示される場合、クラスターは root シークレットが存在する状態でミントモードまたはパススルーモードを使用しています。
- これらの値が表示されない場合、クラスターは root シークレットが削除された状態でミントモードで CCO を使用しています。
手動モードのみを使用する AWS、Google Cloud、またはグローバル Microsoft Azure クラスター: クラスターがクラスター外部からクラウド認証情報を作成および管理するように設定されているかどうかを確認するには、クラスターの
Authenticationオブジェクトの YAML 値を確認する必要があります。-
Administration
Cluster Settings に移動します。 - Cluster Settings ページで、Configuration タブを選択します。
- Configuration resource で Authentication を選択します。
- Authentication details ページで、YAML タブを選択します。
YAML ブロックで、
.spec.serviceAccountIssuerパラメーターの値を確認します。-
クラウドプロバイダーに関連付けられた URL が含まれる値は、CCO がコンポーネントの短期認証情報を使用して手動モードを使用していることを示します。このクラスターは、クラスター外部からクラウド認証情報を作成および管理するために
ccoctlユーティリティーを使用して設定されています。 -
空の値 (
'') は、クラスターが手動モードで CCO を使用しているが、ccoctlユーティリティーを使用して設定されていないことを示します。
-
クラウドプロバイダーに関連付けられた URL が含まれる値は、CCO がコンポーネントの短期認証情報を使用して手動モードを使用していることを示します。このクラスターは、クラスター外部からクラウド認証情報を作成および管理するために
-
Administration
次のステップ
- CCO がミントモードまたはパススルーモードで動作しており、かつ root シークレットが存在するクラスターを更新する場合は、クラウドプロバイダーリソースを更新する必要はなく、更新プロセスの次のステップに進むことができます。
- クラスターが、root シークレットが削除された状態でミントモードで CCO を使用している場合は、更新プロセスの次のステップに進む前に、管理者レベルの認証情報を使用して認証情報シークレットを復元する必要があります。
クラスターが CCO ユーティリティー (
ccoctl) を使用して設定されている場合、次のアクションを実行する必要があります。-
新しいリリースの
CredentialsRequestカスタムリソース (CR) を抽出して準備します。 -
新しいリリースの
ccoctlユーティリティーを設定し、それを使用してクラウドプロバイダーリソースを更新します。 -
upgradeable-toアノテーションを更新して、クラスターの更新準備が完了していることを示します。
-
新しいリリースの
クラスターが手動モードで CCO を使用しており、
ccoctlユーティリティーを使用して設定されていない場合は、以下のアクションを実行する必要があります。-
新しいリリースの
CredentialsRequestカスタムリソース (CR) を抽出して準備します。 - 新しいリリースのクラウドプロバイダーリソースを手動で更新します。
-
upgradeable-toアノテーションを更新して、クラスターの更新準備が完了していることを示します。
-
新しいリリースの
2.2.1.3. CLI を使用した Cloud Credential Operator モードの判別 リンクのコピーリンクがクリップボードにコピーされました!
CLI を使用して、Cloud Credential Operator (CCO) が使用するように設定されているモードを判別できます。
複数の CCO モードをサポートしているのは、Amazon Web Services (AWS)、グローバル Microsoft Azure、および Google Cloud クラスターだけです。
前提条件
- クラスター管理者パーミッションを持つ OpenShift Container Platform アカウントにアクセスできる。
-
OpenShift CLI (
oc) がインストールされている。
手順
-
cluster-adminロールを持つユーザーとしてクラスターのocにログインします。 CCO が使用するように設定されているモードを確認するには、次のコマンドを入力します。
$ oc get cloudcredentials cluster \ -o=jsonpath={.spec.credentialsMode}すべてのプラットフォームですべてがサポートされているわけではありませんが、次の出力値が可能です。
-
'': CCO はデフォルトモードで動作しています。この設定では、CCO は、インストール中に提供されたクレデンシャルに応じて、ミントモードまたはパススルーモードで動作します。 -
Mint: CCO はミントモードで動作しています。 -
Passthrough: CCO はパススルーモードで動作しています。 -
Manual: CCO は手動モードで動作します。
重要spec.credentialsModeが''、Mint、またはManualである AWS、Google Cloud、またはグローバル Microsoft Azure クラスターの特定の設定を確認するには、さらに調査する必要があります。AWS および Google Cloud クラスターは、root シークレットを削除した状態でのミントモードの使用をサポートしています。クラスターがミントモードを使用するように明示的に設定されている場合、またはクラスターがデフォルトでミントモードを使用している場合は、更新する前にクラスターに root シークレットが存在するかどうかを確認する必要があります。
手動モードを使用する AWS、Google Cloud、またはグローバル Microsoft Azure クラスターは、AWS STS、Google Cloud Workload Identity、または Microsoft Entra Workload ID を使用してクラスターの外部からクラウド認証情報を作成および管理するように設定できます。クラスター
Authenticationオブジェクトを調べることで、クラスターがこの戦略を使用しているかどうかを判断できます。-
ミントモードのみを使用する AWS または Google Cloud クラスター: クラスターが root シークレットなしで動作しているかどうかを確認するには、次のコマンドを実行します。
$ oc get secret <secret_name> \ -n=kube-system<secret_name>は、AWS の場合はaws-creds、Google Cloud の場合はgcp-credentialsです。root シークレットが存在する場合、このコマンドの出力にはシークレットに関する情報が返されます。エラーが返された場合、root シークレットはクラスターに存在しません。
手動モードのみを使用する AWS、Google Cloud、またはグローバル Microsoft Azure クラスター: クラスターがクラスター外部からクラウド認証情報を作成および管理するように設定されているかどうかを確認するには、次のコマンドを実行します。
$ oc get authentication cluster \ -o jsonpath \ --template='{ .spec.serviceAccountIssuer }'このコマンドは、クラスター
Authenticationオブジェクトの.spec.serviceAccountIssuerパラメーターの値を表示します。-
クラウドプロバイダーに関連付けられた URL の出力は、CCO がコンポーネントの短期認証情報を使用して手動モードを使用していることを示します。このクラスターは、クラスター外部からクラウド認証情報を作成および管理するために
ccoctlユーティリティーを使用して設定されています。 -
空の出力は、クラスターが手動モードで CCO を使用しているが、
ccoctlユーティリティーを使用して設定されていないことを示します。
-
クラウドプロバイダーに関連付けられた URL の出力は、CCO がコンポーネントの短期認証情報を使用して手動モードを使用していることを示します。このクラスターは、クラスター外部からクラウド認証情報を作成および管理するために
次のステップ
- CCO がミントモードまたはパススルーモードで動作しており、かつ root シークレットが存在するクラスターを更新する場合は、クラウドプロバイダーリソースを更新する必要はなく、更新プロセスの次のステップに進むことができます。
- クラスターが、root シークレットが削除された状態でミントモードで CCO を使用している場合は、更新プロセスの次のステップに進む前に、管理者レベルの認証情報を使用して認証情報シークレットを復元する必要があります。
クラスターが CCO ユーティリティー (
ccoctl) を使用して設定されている場合、次のアクションを実行する必要があります。-
新しいリリースの
CredentialsRequestカスタムリソース (CR) を抽出して準備します。 -
新しいリリースの
ccoctlユーティリティーを設定し、それを使用してクラウドプロバイダーリソースを更新します。 -
upgradeable-toアノテーションを更新して、クラスターの更新準備が完了していることを示します。
-
新しいリリースの
クラスターが手動モードで CCO を使用しており、
ccoctlユーティリティーを使用して設定されていない場合は、以下のアクションを実行する必要があります。-
新しいリリースの
CredentialsRequestカスタムリソース (CR) を抽出して準備します。 - 新しいリリースのクラウドプロバイダーリソースを手動で更新します。
-
upgradeable-toアノテーションを更新して、クラスターの更新準備が完了していることを示します。
-
新しいリリースの
2.2.2. 認証情報要求リソースの抽出と準備 リンクのコピーリンクがクリップボードにコピーされました!
Cloud Credential Operator (CCO) を使用するクラスターを手動モードで更新する前に、新しいリリース用の CredentialsRequest カスタムリソース (CR) を抽出して準備する必要があります。
前提条件
-
仕様している更新バージョンのバージョンに一致する OpenShift CLI (
oc) をインストールしている。 -
cluster-admin権限を持つユーザーとしてクラスターにログインしている。
手順
次のコマンドを実行して、適用する更新のプル仕様を取得します。
$ oc adm upgradeこのコマンドの出力には、次のような利用可能な更新のプル仕様が含まれます。
部分的な出力例
... Recommended updates: VERSION IMAGE 4.15.0 quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032 ...次のコマンドを実行して、使用するリリースイメージを
$RELEASE_IMAGE変数に設定します。$ RELEASE_IMAGE=<update_pull_spec><update_pull_spec>は、使用するリリースイメージのプル仕様です。以下に例を示します。quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032以下のコマンドを実行して、OpenShift Container Platform リリースイメージから
CredentialsRequestカスタムリソース (CR) のリストを抽出します。$ oc adm release extract \ --from=$RELEASE_IMAGE \ --credentials-requests \ --included \1 --to=<path_to_directory_for_credentials_requests>2 このコマンドにより、それぞれの
CredentialsRequestオブジェクトに YAML ファイルが作成されます。リリースイメージの各
CredentialsRequestについて、spec.secretRef.namespaceフィールドのテキストと一致するネームスペースがクラスターに存在することを確認します。このフィールドには、クレデンシャルの設定を保持する生成されたシークレットが保存されます。サンプル AWS
CredentialsRequestオブジェクトapiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: cloud-credential-operator-iam-ro namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AWSProviderSpec statementEntries: - effect: Allow action: - iam:GetUser - iam:GetUserPolicy - iam:ListAccessKeys resource: "*" secretRef: name: cloud-credential-operator-iam-ro-creds namespace: openshift-cloud-credential-operator1 - 1
- このフィールドは、生成されたシークレットを保持するために存在する必要がある namespace を示します。
他のプラットフォームの
CredentialsRequestCR も同様の形式ですが、プラットフォーム固有の異なる値があります。クラスターが
spec.secretRef.namespaceで指定された名前の namespace をまだ持っていないCredentialsRequestCR には、次のコマンドを実行して namespace を作成します。$ oc create namespace <component_namespace>
次のステップ
-
クラスターのクラウド認証情報管理が CCO ユーティリティー (
ccoctl) を使用して設定されている場合は、ccoctlユーティリティーをクラスター更新用に設定し、それを使用してクラウドプロバイダーリソースを更新します。 -
クラスターが
ccoctlユーティリティーを使用して設定されていない場合は、クラウドプロバイダーのリソースを手動で更新します。
2.2.3. クラスター更新のための Cloud Credential Operator ユーティリティーの設定 リンクのコピーリンクがクリップボードにコピーされました!
Cloud Credential Operator (CCO) を手動モードで使用するクラスターをアップグレードして、クラスターの外からクラウド認証情報を作成および管理する場合は、CCO ユーティリティー (ccoctl) バイナリーを抽出して準備します。
ccoctl ユーティリティーは、Linux 環境で実行する必要がある Linux バイナリーです。
前提条件
- クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
-
OpenShift CLI (
oc) がインストールされている。
-
クラスターが、クラスター外部からクラウド認証情報を作成および管理するために、
ccoctlユーティリティーを使用して設定されている。 -
OpenShift Container Platform リリースイメージから
CredentialsRequestカスタムリソース (CR) を抽出し、spec.secretRef.namespaceフィールドのテキストと一致する namespace がクラスター内に存在している。
手順
次のコマンドを実行して、OpenShift Container Platform リリースイメージの変数を設定します。
$ RELEASE_IMAGE=$(oc get clusterversion -o jsonpath={..desired.image})以下のコマンドを実行して、OpenShift Container Platform リリースイメージから CCO コンテナーイメージを取得します。
$ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)注記$RELEASE_IMAGEのアーキテクチャーが、ccoctlツールを使用する環境のアーキテクチャーと一致していることを確認してください。以下のコマンドを実行して、OpenShift Container Platform リリースイメージ内の CCO コンテナーイメージから
ccoctlバイナリーを抽出します。$ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret次のコマンドを実行して、権限を変更して
ccoctlを実行可能にします。$ chmod 775 ccoctl
検証
ccoctlが使用できることを確認するには、help ファイルを表示します。コマンドを実行するときは、相対ファイル名を使用します。以下に例を示します。$ ./ccoctl.rhel9出力例
OpenShift credentials provisioning tool Usage: ccoctl [command] Available Commands: alibabacloud Manage credentials objects for alibaba cloud aws Manage credentials objects for AWS cloud azure Manage credentials objects for Azure gcp Manage credentials objects for Google cloud help Help about any command ibmcloud Manage credentials objects for IBM Cloud nutanix Manage credentials objects for Nutanix Flags: -h, --help help for ccoctl Use "ccoctl [command] --help" for more information about a command.
2.2.4. Cloud Credential Operator ユーティリティーを使用したクラウドプロバイダーリソースの更新 リンクのコピーリンクがクリップボードにコピーされました!
CCO ユーティリティー (ccoctl) を使用して設定された OpenShift Container Platform クラスターをアップグレードするプロセスは、インストール時にクラウドプロバイダーリソースを作成するプロセスに似ています。
AWS クラスターでは、一部の ccoctl コマンドが AWS API 呼び出しを行い、AWS リソースを作成または変更します。--dry-run フラグを使用して、API 呼び出しを回避できます。このフラグを使用すると、代わりにローカルファイルシステムに JSON ファイルが作成されます。JSON ファイルを確認して変更し、AWS CLI ツールで --cli-input-json パラメーターを使用して適用できます。
前提条件
-
OpenShift Container Platform リリースイメージから
CredentialsRequestカスタムリソース (CR) を抽出し、spec.secretRef.namespaceフィールドのテキストと一致する namespace がクラスター内に存在している。 -
リリースイメージから
ccoctlバイナリーを抽出して設定している。
手順
ccoctlツールを使用して、クラウドプロバイダーのコマンドを実行して、すべてのCredentialsRequestオブジェクトを処理します。以下のコマンドはCredentialsRequestオブジェクトを処理します。例2.1 Amazon Web Services (AWS)
$ ccoctl aws create-all \1 --name=<name> \2 --region=<aws_region> \3 --credentials-requests-dir=<path_to_credentials_requests_directory> \4 --output-dir=<path_to_ccoctl_output_dir> \5 --create-private-s3-bucket6 - 1
- AWS リソースを個別に作成するには、「カスタマイズを使用した AWS へのクラスターのインストール」コンテンツの「AWS リソースの個別の作成」手順を使用します。このオプションは、AWS リソースを変更する前に
ccoctlツールが作成する JSON ファイルを確認する必要がある場合、またはccoctlツールが AWS リソースを自動的に作成するために使用するプロセスが組織の要件を満たしていない場合に役立つ可能性があります。 - 2
- 追跡用に作成されたクラウドリソースにタグを付けるために使用される名前です。
- 3
- クラウドリソースが作成される AWS リージョンです。
- 4
- コンポーネント
CredentialsRequestオブジェクトのファイルを含むディレクトリーを指定します。 - 5
- オプション:
ccoctlユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。 - 6
- オプション: デフォルトでは、
ccoctlユーティリティーは OpenID Connect (OIDC) 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。代わりに、パブリック CloudFront ディストリビューション URL を介して IAM アイデンティティープロバイダーがアクセスするプライベート S3 バケットに OIDC 設定を保存するには、--create-private-s3-bucketパラメーターを使用します。
例2.2 Google Cloud
$ ccoctl gcp create-all \ --name=<name> \1 --region=<gcp_region> \2 --project=<gcp_project_id> \3 --credentials-requests-dir=<path_to_credentials_requests_directory> \4 --output-dir=<path_to_ccoctl_output_dir>5 - 1
- トラッキングに使用される、作成されたすべての Google Cloud リソースのユーザー定義名を指定します。
- 2
- クラウドリソースを作成する Google Cloud リージョンを指定します。
- 3
- クラウドリソースを作成する Google Cloud プロジェクト ID を指定します。
- 4
- Google Cloud サービスアカウントを作成するために、
CredentialsRequestマニフェストのファイルを含むディレクトリーを指定します。 - 5
- オプション:
ccoctlユーティリティーがオブジェクトを作成するディレクトリーを指定します。デフォルトでは、ユーティリティーは、コマンドが実行されるディレクトリーにオブジェクトを作成します。
例2.3 IBM Cloud
$ ccoctl ibmcloud create-service-id \ --credentials-requests-dir=<path_to_credential_requests_directory> \1 --name=<cluster_name> \2 --output-dir=<installation_directory> \3 --resource-group-name=<resource_group_name>4 例2.4 Microsoft Azure
$ ccoctl azure create-managed-identities \ --name <azure_infra_name> \1 --output-dir ./output_dir \ --region <azure_region> \2 --subscription-id <azure_subscription_id> \3 --credentials-requests-dir <path_to_directory_for_credentials_requests> \ --issuer-url "${OIDC_ISSUER_URL}" \4 --dnszone-resource-group-name <azure_dns_zone_resourcegroup_name> \5 --installation-resource-group-name "${AZURE_INSTALL_RG}"6 - 1
nameパラメーターの値は、Azure リソースグループを作成するために使用します。新しい Azure リソースグループを作成する代わりに既存の Azure リソースグループを使用するには、--oidc-resource-group-nameを指定し、その値として既存のグループ名を使用します。- 2
- 既存のクラスターのリージョンを指定します。
- 3
- 既存のクラスターのサブスクリプション ID を指定します。
- 4
- 既存のクラスターから OIDC 発行者 URL を指定します。この値は、以下のコマンドを実行して取得できます。
$ oc get authentication cluster \ -o jsonpath \ --template='{ .spec.serviceAccountIssuer }' - 5
- DNS ゾーンを含むリソースグループの名前を指定します。
- 6
- Azure リソースグループを指定します。この値は、以下のコマンドを実行して取得できます。
$ oc get infrastructure cluster \ -o jsonpath \ --template '{ .status.platformStatus.azure.resourceGroupName }'
例2.5 Nutanix
$ ccoctl nutanix create-shared-secrets \ --credentials-requests-dir=<path_to_credentials_requests_directory> \1 --output-dir=<ccoctl_output_dir> \2 --credentials-source-filepath=<path_to_credentials_file>3 OpenShift Container Platform リリースイメージの各
CredentialsRequestオブジェクトで定義されているとおり、ccoctlはCredentialsRequestオブジェクトごとに必要なプロバイダーリソースと権限ポリシーを作成します。次のコマンドを実行して、シークレットをクラスターに適用します。
$ ls <path_to_ccoctl_output_dir>/manifests/*-credentials.yaml | xargs -I{} oc apply -f {}
検証
クラウドプロバイダーにクエリーを実行することで、必要なプロバイダーのリソースと権限ポリシーが作成されていることを確認できます。詳細は、適切なクラウドプロバイダーのドキュメントでロールまたはサービスアカウントの一リストを参照してください。
次のステップ
-
upgradeable-toアノテーションを更新して、クラスターをアップグレードする準備ができていることを示します。
2.2.5. クラウドプロバイダーのリソースを手動で更新する リンクのコピーリンクがクリップボードにコピーされました!
手動でメンテナンスされる認証情報でクラスターをアップグレードする前に、アップグレードするリリースイメージ用に新しい認証情報のシークレットを作成する必要があります。また、既存の認証情報に必要なアクセス許可を確認し、それらのコンポーネントの新しいリリースでの新しいアクセス許可要件に対応する必要があります。
前提条件
-
OpenShift Container Platform リリースイメージから
CredentialsRequestカスタムリソース (CR) を抽出し、spec.secretRef.namespaceフィールドのテキストと一致する namespace がクラスター内に存在している。
手順
新しいリリースイメージで追加される
CredentialsRequestカスタムリソースのシークレットを含む YAML ファイルを作成します。シークレットは、それぞれのCredentialsRequestオブジェクトに、spec.secretRefに定義される namespace およびシークレット名を使用して保存する必要があります。例2.6 サンプル AWS YAML ファイル
シークレットを含むサンプル AWS
CredentialsRequestオブジェクトapiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: <component_credentials_request> namespace: openshift-cloud-credential-operator ... spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AWSProviderSpec statementEntries: - effect: Allow action: - s3:CreateBucket - s3:DeleteBucket resource: "*" ... secretRef: name: <component_secret> namespace: <component_namespace> ...サンプル AWS
SecretオブジェクトapiVersion: v1 kind: Secret metadata: name: <component_secret> namespace: <component_namespace> data: aws_access_key_id: <base64_encoded_aws_access_key_id> aws_secret_access_key: <base64_encoded_aws_secret_access_key>例2.7 サンプル Azure YAML ファイル
注記Global Azure と Azure Stack Hub は、同じ
CredentialsRequestオブジェクトとシークレット形式を使用します。シークレットを含むサンプル Azure
CredentialsRequestオブジェクトapiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: <component_credentials_request> namespace: openshift-cloud-credential-operator ... spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AzureProviderSpec roleBindings: - role: Contributor ... secretRef: name: <component_secret> namespace: <component_namespace> ...サンプル Azure
SecretオブジェクトapiVersion: v1 kind: Secret metadata: name: <component_secret> namespace: <component_namespace> data: azure_subscription_id: <base64_encoded_azure_subscription_id> azure_client_id: <base64_encoded_azure_client_id> azure_client_secret: <base64_encoded_azure_client_secret> azure_tenant_id: <base64_encoded_azure_tenant_id> azure_resource_prefix: <base64_encoded_azure_resource_prefix> azure_resourcegroup: <base64_encoded_azure_resourcegroup> azure_region: <base64_encoded_azure_region>例2.8 サンプル Google Cloud YAML ファイル
シークレットを含む Google Cloud
CredentialsRequestオブジェクトのサンプルapiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: <component_credentials_request> namespace: openshift-cloud-credential-operator ... spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: GCPProviderSpec predefinedRoles: - roles/iam.securityReviewer - roles/iam.roleViewer skipServiceCheck: true ... secretRef: name: <component_secret> namespace: <component_namespace> ...サンプル Google Cloud
SecretオブジェクトapiVersion: v1 kind: Secret metadata: name: <component_secret> namespace: <component_namespace> data: service_account.json: <base64_encoded_gcp_service_account_file>-
シークレットに保存される既存の認証情報の
CredentialsRequestカスタムリソースにパーミッション要件を変更した場合は、必要に応じてパーミッションを更新します。
次のステップ
-
upgradeable-toアノテーションを更新して、クラスターをアップグレードする準備ができていることを示します。
2.2.6. クラスターがアップグレードの準備ができていることを示す リンクのコピーリンクがクリップボードにコピーされました!
手動で管理される認証情報を使用するクラスターの Cloud Credential Operator (CCO) の Upgradable ステータスは、デフォルトでは False です。
前提条件
-
アップグレード先のリリースイメージについて、手動で、または Cloud Credential Operator ユーティリティー (
ccoctl) を使用して、新しい認証情報を処理しました。 -
OpenShift CLI (
oc) がインストールされている。
手順
-
cluster-adminロールを持つユーザーとしてクラスターのocにログインします。 次のコマンドを実行して
CloudCredentialリソースを編集し、metadataフィールド内にupgradeable-toアノテーションを追加します。$ oc edit cloudcredential cluster追加するテキスト
... metadata: annotations: cloudcredential.openshift.io/upgradeable-to: <version_number> ...<version_number>はアップグレード先のバージョンで、形式はx.y.zです。たとえば、OpenShift Container Platform 4.12.2 には4.12.2を使用します。アノテーションを追加してから、upgradeable のステータスが変更されるまで、数分かかる場合があります。
検証
-
Web コンソールの Administrator パースペクティブで、Administration
Cluster Settings に移動します。 CCO ステータスの詳細を表示するには、Cluster Operators リストで cloud-credential をクリックします。
-
Conditions セクションの Upgradeable ステータスが False の場合に、
upgradeable-toアノテーションに間違いがないことを確認します。
-
Conditions セクションの Upgradeable ステータスが False の場合に、
- Conditions セクションの Upgradeable ステータスが True の場合、OpenShift Container Platform のアップグレードを開始します。