18.3. passthrough モードの使用
passthrough モードは、Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP)、Red Hat OpenStack Platform (RHOSP)、Red Hat Virtualization (RHV)、および VMware vSphere でサポートされます。
passthrough モードでは、Cloud Credential Operator (CCO) は提供されるクラウド認証情報を、コンポーネントを要求するコンポーネントに渡します。認証情報には、インストールを実行し、クラスター内のコンポーネントで必要な操作を完了するためのパーミッションが必要ですが、認証情報を新たに作成する必要はありません。CCO は、passthrough モードで、追加の制限されたスコープの認証情報の作成を試行しません。
18.3.1. passthrough モードのパーミッション要件
passthrough モードで CCO を使用する場合、指定する認証情報が OpenShift Container Platform を実行し、インストールしているクラウドの各種要件を満たしていることを確認してください。CCO が CredentialsRequest
CR を作成するコンポーネントに渡す指定された認証情報が不十分な場合に、そのコンポーネントは、パーミッションがない API の呼び出しを試行する際にエラーを報告します。
18.3.1.1. Amazon Web Services (AWS) パーミッション
AWS の passthrough モードに指定する認証情報には、実行し、インストールしている OpenShift Container Platform のバージョンで必要なすべての CredentialsRequest
CR に必要なすべての必須パーミッションがなければなりません。
必要な CredentialsRequest
CR を見つけるには、AWS の IAM の手動作成 について参照してください。
18.3.1.2. Microsoft Azure パーミッション
Azure の passthrough モードに指定する認証情報には、実行し、インストールしている OpenShift Container Platform のバージョンで必要なすべての CredentialsRequest
CR に必要なすべての必須パーミッションがなければなりません。
必要な CredentialsRequest
CR を見つけるには、Azure の IAM の手動作成 について参照してください。
18.3.1.3. Google Cloud Platform (GCP) パーミッション
GCP の passthrough モードに指定する認証情報には、実行し、インストールしている OpenShift Container Platform のバージョンで必要なすべての CredentialsRequest
CR に必要なすべての必須パーミッションがなければなりません。
必要な CredentialsRequest
CR を見つけるには、GCP の IAM の手動作成 について参照してください。
18.3.1.4. Red Hat OpenStack Platform (RHOSP) パーミッション
OpenShift Container Platform クラスターを RHOSP にインストールするには、CCO では member
ユーザーロールのパーミッションと共に認証情報が必要になります。
18.3.1.5. Red Hat Virtualization (RHV) パーミッション
OpenShift Container Platform クラスターを RHV にインストールするには、CCO には、以下の権限と共に認証情報が必要になります。
-
DiskOperator
-
DiskCreator
-
UserTemplateBasedVm
-
TemplateOwner
-
TemplateCreator
-
OpenShift Container Platform デプロイメントにターゲットが設定される特定クラスターの
ClusterAdmin
18.3.1.6. VMware vSphere パーミッション
OpenShift Container Platform クラスターを VMware vSphere にインストールするには、CCO には以下の vSphere 権限と共に認証情報が必要になります。
カテゴリー | 権限 |
---|---|
データストア | 領域の割り当て |
フォルダー | フォルダーの作成、フォルダーの削除 |
vSphere タグ | すべての権限 |
ネットワーク | ネットワークの割り当て |
リソース | 仮想マシンのリソースプールへの割り当て |
プロファイル駆動型ストレージ | すべての権限 |
vApp | すべての権限 |
仮想マシン | すべての権限 |
18.3.2. 管理者の認証情報のルートシークレット形式
各クラウドプロバイダーは、kube-system
namespace の認証情報ルートシークレットを使用します。これは、すべての認証情報要求を満たし、それぞれのシークレットを作成するために使用されます。これは、mint モード で新規の認証情報を作成するか、または passthrough モード で認証情報 root シークレットをコピーして実行します。
シークレットの形式はクラウドごとに異なり、それぞれの CredentialsRequest
シークレットにも使用されます。
Amazon Web Services (AWS) シークレット形式
apiVersion: v1 kind: Secret metadata: namespace: kube-system name: aws-creds stringData: aws_access_key_id: <base64-encoded_access_key_id> aws_secret_access_key: <base64-encoded_secret_access_key>
Microsoft Azure シークレットの形式
apiVersion: v1 kind: Secret metadata: namespace: kube-system name: azure-credentials stringData: azure_subscription_id: <base64-encoded_subscription_id> azure_client_id: <base64-encoded_client_id> azure_client_secret: <base64-encoded_client_secret> azure_tenant_id: <base64-encoded_tenant_id> azure_resource_prefix: <base64-encoded_resource_prefix> azure_resourcegroup: <base64-encoded_resource_group> azure_region: <base64-encoded_region>
Microsoft Azure では、認証情報シークレット形式には、それぞれのクラスターのインストールにランダムに生成されるクラスターのインフラストラクチャー ID が含まれる必要のある 2 つのプロパティーがあります。この値は、マニフェストの作成後に確認できます。
$ cat .openshift_install_state.json | jq '."*installconfig.ClusterID".InfraID' -r
出力例
mycluster-2mpcn
この値は、以下のようにシークレットデータで使用されます。
azure_resource_prefix: mycluster-2mpcn azure_resourcegroup: mycluster-2mpcn-rg
Google Cloud Platform (GCP) シークレット形式
apiVersion: v1 kind: Secret metadata: namespace: kube-system name: gcp-credentials stringData: service_account.json: <base64-encoded_service_account>
Red Hat OpenStack Platform (RHOSP) シークレット形式
apiVersion: v1 kind: Secret metadata: namespace: kube-system name: openstack-credentials data: clouds.yaml: <base64-encoded_cloud_creds> clouds.conf: <base64-encoded_cloud_creds_init>
Red Hat Virtualization (RHV) シークレット形式
apiVersion: v1 kind: Secret metadata: namespace: kube-system name: ovirt-credentials data: ovirt_url: <base64-encoded_url> ovirt_username: <base64-encoded_username> ovirt_password: <base64-encoded_password> ovirt_insecure: <base64-encoded_insecure> ovirt_ca_bundle: <base64-encoded_ca_bundle>
VMware vSphere シークレット形式
apiVersion: v1 kind: Secret metadata: namespace: kube-system name: vsphere-creds data: vsphere.openshift.example.com.username: <base64-encoded_username> vsphere.openshift.example.com.password: <base64-encoded_password>
18.3.3. passthrough モードの認証情報のメンテナンス
CredentialsRequest
CR がクラスターのアップグレード時に変更される場合、各種要件を満たすために passthrough モードの認証情報を手動で更新する必要があります。アップグレード時の認証情報の問題を回避するには、アップグレードの前に、新規バージョンの OpenShift Container Platform のリリースイメージで CredentialsRequest
CR を確認します。クラウドプロバイダーに必要な CredentialsRequest
CR を見つけるには、AWS、Azure、または GCP の IAM の手動作成について参照してください。
18.3.3.1. クラウドプロバイダーの認証情報の手動によるローテーション
クラウドプロバイダーの認証情報が何らかの理由で変更される場合、クラウドプロバイダーの認証情報の管理に Cloud Credential Operator (CCO) が使用するシークレットを手動で更新する必要があります。
クラウド認証情報をローテーションするプロセスは、CCO を使用するように設定されているモードによって変わります。mint モードを使用しているクラスターの認証情報をローテーションした後に、削除された認証情報で作成されたコンポーネントの認証情報は手動で削除する必要があります。
前提条件
クラスターは、使用している CCO モードでのクラウド認証情報の手動ローテーションをサポートするプラットフォームにインストールされている。
- passthrough モードは、Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP)、Red Hat OpenStack Platform (RHOSP)、Red Hat Virtualization (RHV)、および VMware vSphere でサポートされます。
- クラウドプロバイダーとのインターフェイスに使用される認証情報を変更している。
- 新規認証情報には、モードの CCO がクラスターで使用されるように設定するのに十分なパーミッションがある。
手順
-
Web コンソールの Administrator パースペクティブで、Workloads
Secrets に移動します。 Secrets ページの表で、クラウドプロバイダーのルートシークレットを見つけます。
プラットフォーム シークレット名 AWS
aws-creds
Azure
azure-credentials
GCP
gcp-credentials
RHOSP
openstack-credentials
RHV
ovirt-credentials
VMware vSphere
vsphere-creds
- シークレットと同じ行にある Options メニュー をクリックし、Edit Secret を選択します。
- Value フィールドの内容を記録します。この情報を使用して、認証情報の更新後に値が異なることを確認できます。
- Value フィールドのテキストをクラウドプロバイダーの新規の認証情報で更新し、Save をクリックします。
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
検証
認証情報が変更されたことを確認するには、以下を実行します。
-
Web コンソールの Administrator パースペクティブで、Workloads
Secrets に移動します。 - Value フィールドの内容が変更されていることを確認します。
18.3.4. インストール後のパーミッションの縮小
passthrough モードを使用する場合、各コンポーネントには他のすべてのコンポーネントによって使用されるパーミッションと同じパーミッションがあります。インストール後にパーミッションを縮小しない場合、すべてのコンポーネントにはインストーラーの実行に必要な幅広いパーミッションが付与されます。
インストール後に、認証情報のパーミッションを、クラスターの実行に必要なパーミッションに制限できます。これは、使用している OpenShift Container Platform バージョンのリリースイメージの CredentialsRequest
CR で定義されます。
AWS、Azure、または GCP に必要な CredentialsRequest
CR を見つけ、CCO が使用するパーミッションを変更する方法については、AWS、Azure、または GCP の IAM の手動作成について参照してください。