7.3. GCP の IAM の手動作成
クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境や、管理者がクラスター kube-system
namespace に管理者レベルの認証情報シークレットを保存する選択をしない場合に、クラスターのインストール前に Cloud Credential Operator (CCO) を手動モードにすることができます。
7.3.1. 管理者レベルのシークレットを kube-system プロジェクトに保存する代替方法
Cloud Credential Operator (CCO) は、クラウドプロバイダーの認証情報を Kubernetes カスタムリソース定義 (CRD) として管理します。credentialsMode
パラメーターの異なる値を install-config.yaml
ファイルに設定し、組織のセキュリティー要件に応じて CCO を設定できます。
管理者レベルの認証情報シークレットをクラスターの kube-system
プロジェクトに保存する選択をしない場合、OpenShift Container Platform をインストールする際に以下のいずれかのオプションを選択できます。
クラウド認証情報を手動で管理 します。
CCO の
credentialsMode
パラメーターをManual
に設定し、クラウド認証情報を手動で管理できます。手動モードを使用すると、クラスターに管理者レベルの認証情報を保存する必要なく、各クラスターコンポーネントに必要なパーミッションのみを指定できます。お使いの環境でクラウドプロバイダーのパブリック IAM エンドポイントへの接続がない場合も、このモードを使用できます。ただし、各アップグレードについて、パーミッションを新規リリースイメージを使用して手動で調整する必要があります。また、それらを要求するすべてのコンポーネントについて認証情報を手動で指定する必要があります。OpenShift Container Platform を mint モードでインストールした後に、管理者レベルの認証情報シークレットを削除 します。
credentialsMode
パラメーターがMint
に設定された状態で CCO を使用している場合、OpenShift Container Platform のインストール後に管理者レベルの認証情報を削除したり、ローテーションしたりできます。Mint モードは、CCO のデフォルト設定です。このオプションには、インストール時に管理者レベルの認証情報が必要になります。管理者レベルの認証情報はインストール時に、付与された一部のパーミッションと共に他の認証情報を生成するために使用されます。元の認証情報シークレットはクラスターに永続的に保存されません。
z-stream 以外のアップグレードの前に、認証情報のシークレットを管理者レベルの認証情報と共に元に戻す必要があります。認証情報が存在しない場合は、アップグレードがブロックされる可能性があります。
利用可能なすべての CCO 認証情報モードとそれらのサポートされるプラットフォームの詳細については、Cloud Credential Operator について 参照してください。
7.3.2. IAM の手動作成
Cloud Credential Operator (CCO) は、クラウドアイデンティティーおよびアクセス管理 (IAM) API に到達できない環境にインストールする前に手動モードに配置できます。管理者はクラスター kube-system
namespace に管理者レベルの認証情報シークレットを保存しないようにします。
手順
インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行して
install-config.yaml
ファイルを作成します。$ openshift-install create install-config --dir <installation_directory>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。install-config.yaml
設定ファイルを編集し、credentialsMode
パラメーターがManual
に設定されるようにします。サンプル
install-config.yaml
設定ファイルapiVersion: v1 baseDomain: cluster1.example.com credentialsMode: Manual 1 compute: - architecture: amd64 hyperthreading: Enabled ...
- 1
- この行は、
credentialsMode
パラメーターをManual
に設定するために追加されます。
マニフェストを生成するには、インストールプログラムが含まれるディレクトリーから以下のコマンドを実行します。
$ openshift-install create manifests --dir <installation_directory>
ここで、
<installation_directory>
は、インストールプログラムがファイルを作成するディレクトリーに置き換えます。インストールプログラムが含まれるディレクトリーから、以下のコマンドを実行して、
openshift-install
バイナリーがビルドされている OpenShift Container Platform リリースイメージの詳細を取得します。$ openshift-install version
出力例
release image quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64
以下のコマンドを実行して、デプロイするクラウドをターゲットとするリリースイメージですべての
CredentialsRequest
オブジェクトを見つけます。$ oc adm release extract quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64 \ --credentials-requests \ --cloud=gcp
このコマンドにより、それぞれの
CredentialsRequest
オブジェクトに YAML ファイルが作成されます。サンプル
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/storage.admin - roles/iam.serviceAccountUser skipServiceCheck: true ...
以前に生成した
openshift-install
マニフェストディレクトリーにシークレットの YAML ファイルを作成します。シークレットは、それぞれのCredentialsRequest
オブジェクトについてspec.secretRef
に定義される namespace およびシークレット名を使用して保存する必要があります。シークレットを含む
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 ... secretRef: name: <component-secret> namespace: <component-namespace> ...
サンプル
Secret
オブジェクトapiVersion: v1 kind: Secret metadata: name: <component-secret> namespace: <component-namespace> data: service_account.json: <base64_encoded_gcp_service_account_file>
手動でメンテナンスされる認証情報を使用するクラスターをアップグレードする前に、CCO がアップグレード可能な状態であることを確認します。詳細は、クラウドプロバイダーのインストールコンテンツの手動でメンテナンスされる認証情報を使用したクラスターのアップグレードについてのセクションを参照してください。
7.3.3. 手動でメンテナンスされた認証情報を使用したクラスターのアップグレード
手動でメンテナンスされる認証情報をを含むクラスターの Cloud Credential Operator (CCO) の upgradable
ステータスはデフォルトで false
となります。
-
4.8 から 4.9 などのマイナーリリースの場合には、このステータスを使用することで、パーミッションを更新して
CloudCredential
リソースにアノテーションを付けてパーミッションが次のバージョンの要件に合わせて更新されていることを指定するまで、アップグレードができないようになります。このアノテーションは、Upgradable
ステータスをTrue
に変更します。 - 4.9.0 から 4.9.1 などの z-stream リリースの場合には、パーミッションは追加または変更されないため、アップグレードはブロックされません。
手動でメンテナンスされる認証情報でクラスターをアップグレードする前に、アップグレードするリリースイメージ用に認証情報を新規作成する必要があります。さらに、既存の認証情報に必要なパーミッションを確認し、これらのコンポーネントの新規リリースの新しいパーミッション要件に対応する必要があります。
手順
新規リリースの
CredentialsRequest
カスタムリソースを抽出して検査します。クラウドプロバイダーのインストールコンテンツの IAM の手動作成についてのセクションでは、クラウドに必要な認証情報を取得し、使用する方法について説明します。
クラスターで手動でメンテナンスされる認証情報を更新します。
-
新規リリースイメージによって追加される
CredentialsRequest
カスタムリソースの新規のシークレットを作成します。 -
シークレットに保存される既存の認証情報の
CredentialsRequest
カスタムリソースにパーミッション要件を変更した場合は、必要に応じてパーミッションを更新します。
-
新規リリースイメージによって追加される
新規リリースですべてのシークレットが正しい場合は、クラスターをアップグレードする準備が整っていることを示します。
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform CLI にログインします。 CloudCredential
リソースを編集して、metadata
フィールドにupgradeable-to
アノテーションを追加します。$ oc edit cloudcredential cluster
追加するテキスト
... metadata: annotations: cloudcredential.openshift.io/upgradeable-to: <version_number> ...
ここで、
<version_number>
は、アップグレードするバージョン (x.y.z
形式) に置き換えます。例: OpenShift Container Platform4.8.2
(OpenShift Container Platform 4.8.2 の場合)アノテーションを追加してから、upgradeable のステータスが変更されるまで、数分かかる場合があります。
-
CCO がアップグレードできることを確認します。
-
Web コンソールの Administrator パースペクティブで、Administration
Cluster Settings に移動します。 - CCO ステータスの詳細を表示するには、Cluster Operators 一覧で cloud-credential をクリックします。
-
Conditions セクションの Upgradeable ステータスが False の場合に、
upgradeable-to
アノテーションに間違いがないことを確認します。
-
Web コンソールの Administrator パースペクティブで、Administration
Conditions セクションの Upgradeable ステータスが True の場合には、OpenShift Container Platform のアップグレードを開始できます。
:_content-type: CONCEPT
7.3.4. mint モード
mint モードは、OpenShift Container Platform のデフォルトの Cloud Credential Operator (CCO) の認証情報モードです。このモードでは、CCO は提供される管理者レベルのクラウド認証情報を使用してクラスターを実行します。Mint モードは AWS と GCP でサポートされています。
mint モードでは、admin
認証情報は kube-system
namespace に保存され、次に CCO によってクラスターの CredentialsRequest
オブジェクトを処理し、特定のパーミッションでそれぞれのユーザーを作成するために使用されます。
mint モードには以下の利点があります。
- 各クラスターコンポーネントにはそれぞれが必要なパーミッションのみがあります。
- クラウド認証情報の自動の継続的な調整が行われます。これには、アップグレードに必要になる可能性のある追加の認証情報またはパーミッションが含まれます。
1 つの不利な点として、mint モードでは、admin
認証情報がクラスターの kube-system
シークレットに保存される必要があります。
7.3.5. 管理者レベルの認証情報の削除またはローテーション機能を持つ mint モード
現時点で、このモードは AWS および GCP でのみサポートされます。
このモードでは、ユーザーは通常の mint モードと同様に管理者レベルの認証情報を使用して OpenShift Container Platform をインストールします。ただし、このプロセスはクラスターのインストール後の管理者レベルの認証情報シークレットを削除します。
管理者は、Cloud Credential Operator に読み取り専用の認証情報について独自の要求を行わせることができます。これにより、すべての CredentialsRequest
オブジェクトに必要なパーミッションがあることの確認が可能になります。そのため、いずれかの変更が必要にならない限り、管理者レベルの認証情報は必要になりません。関連付けられた認証情報が削除された後に、必要な場合は、これは基礎となるクラウドで破棄するか、または非アクティブにできます。
z-stream 以外のアップグレードの前に、認証情報のシークレットを管理者レベルの認証情報と共に元に戻す必要があります。認証情報が存在しない場合は、アップグレードがブロックされる可能性があります。
管理者レベルの認証情報はクラスターに永続的に保存されません。
これらの手順を実行するには、短い期間にクラスターでの管理者レベルの認証情報が必要になります。また、アップグレードごとに管理者レベルの認証情報を使用してシークレットを手動で再インストールする必要があります。
7.3.6. 次のステップ
OpenShift Container Platform クラスターをインストールします。
- インストーラーでプロビジョニングされるインフラストラクチャーのデフォルトオプションを使用した クラスターの GCP へのクイックインストール
- インストーラーでプロビジョニングされるインフラストラクチャーへのクラウドのカスタマイズを使用したクラスターのインストール
- インストーラーでプロビジョニングされるインフラストラクチャーへのネットワークのカスタマイズを使用したクラスターのインストール