19.5. コンポーネントの短期認証情報を使用した手動モード
インストール中に、手動モードで動作するように Cloud Credential Operator (CCO) を設定し、CCO ユーティリティー (ccoctl
) を使用して、OpenShift Container Platform クラスターの外部で作成および管理される個々のコンポーネントに短期セキュリティー認証情報を実装できます。
この認証情報戦略は、Amazon Web Services (AWS)、Google Cloud Platform (GCP)、およびグローバル Microsoft Azure でのみサポートされています。この戦略は、新しい OpenShift Container Platform クラスターのインストール中に設定する必要があります。この機能を使用するために、既存のクラスターが別のクレデンシャルストラテジーを使用するように設定することはできません。
クラウドプロバイダーは、この認証方法の実装にさまざまな用語を使用します。
クラウドプロバイダー | プロバイダーの命名法 |
---|---|
Amazon Web Services (AWS) | AWS Security Token Service (STS) |
Google Cloud Platform (GCP) | GCP Workload Identity |
Global Microsoft Azure | Microsoft Entra Workload ID |
19.5.1. AWS Security Token Service
STS での手動モードでは、個別の OpenShift Container Platform クラスターコンポーネントは AWS Security Token Service (STS) を使用して、短期的かつ権限が制限されたセキュリティー認証情報を提供する IAM ロールをコンポーネントに割り当てます。これらの認証情報は、AWS API 呼び出しを行う各コンポーネントに固有の IAM ロールに関連付けられます。
19.5.1.1. AWS Security Token Service の認証プロセス
AWS Security Token Service (STS) と AssumeRole
API アクションを使用すると、Pod が IAM ロールポリシーで定義されたアクセスキーを取得できるようになります。
OpenShift Container Platform クラスターには、Kubernetes サービスアカウント署名サービスが組み込まれています。このサービスは、秘密鍵を使用してサービスアカウント JSON Web トークン (JWT) に署名します。サービスアカウントトークンを必要とする Pod は、Pod 仕様を通じてサービスアカウントトークンを要求します。Pod が作成されてノードに割り当てられると、そのノードがサービスアカウント署名サービスから署名付きサービスアカウントを取得し、それを Pod にマウントします。
STS を使用するクラスターでは、Kubernetes 設定シークレットに IAM ロール ID が含まれています。ワークロードは、この IAM ロール ID のアイデンティティーを引き継ぎます。ワークロードに発行された署名付きサービスアカウントトークンが AWS の設定と一致するため、AWS STS は指定された IAM ロールのアクセスキーをワークロードに付与できます。
AWS STS は、次の条件を満たすサービスアカウントトークンを含む要求に対してのみアクセスキーを付与します。
- トークンの名前と namespace が、サービスアカウントの名前と namespace と一致している。
- トークンが公開鍵と一致する鍵によって署名されている。
クラスターで使用されるサービスアカウント署名鍵の公開鍵ペアは、AWS S3 バケットに保存されます。AWS STS のフェデレーションによって、サービスアカウントトークンの署名が S3 バケットに保存されている公開鍵と一致していることが検証されます。
19.5.1.1.1. AWS STS の認証フロー
次の図は、AWS STS を使用する場合の AWS と OpenShift Container Platform クラスター間の認証フローを示しています。
- トークン署名 は、OpenShift Container Platform クラスター上の Kubernetes サービスアカウント署名サービスです。
- Pod 内の Kubernetes サービスアカウント は、署名付きサービスアカウントトークンです。
図19.2 AWS Security Token Service の認証フロー
新しい認証情報と更新された認証情報の要求は、適切に設定された AWS IAM OpenID Connect (OIDC) ID プロバイダーと AWS IAM ロールを組み合わせて使用することで自動化されます。AWS IAM によって信頼されているサービスアカウントトークンは、OpenShift Container Platform によって署名されており、Pod に展開して認証に使用できます。
19.5.1.1.2. AWS STS のトークン更新
Pod が使用する署名付きサービスアカウントトークンは、一定期間が経過すると期限切れになります。AWS STS を使用するクラスターの場合、この期間は 3600 秒、つまり 1 時間です。
トークンの更新は、Pod が割り当てられているノード上の kubelet により実行されます。kubelet は、トークンの有効期間の 80% を超えると、トークンのローテーションを試みます。
19.5.1.1.3. AWS STS の OpenID Connect の要件
OIDC 設定の暗号鍵のパブリック部分は、パブリックまたはプライベート S3 バケットに保存できます。
OIDC 仕様では HTTPS を使用する必要があります。AWS サービスは、OIDC ドキュメントを JSON Web Key Set (JWKS) 公開鍵の形式で公開するパブリックエンドポイントを必須としています。これにより、AWS サービスは、Kubernetes によって署名されたバインドされたトークンを検証し、証明書を信頼するかどうかを判断できるようになります。そのため、どちらの S3 バケットオプションでもパブリック HTTPS エンドポイントは必要です。プライベートエンドポイントはサポートされません。
AWS STS を使用するには、AWS STS サービスのパブリック AWS バックボーンが、パブリック S3 バケット、またはパブリック CloudFront エンドポイントを備えたプライベート S3 バケットと通信できる必要があります。インストール時に、CredentialsRequest
オブジェクトの処理に使用するバケットのタイプを選択できます。
-
デフォルトでは、CCO ユーティリティー (
ccoctl
) が、OIDC 設定ファイルをパブリック S3 バケットに保存し、S3 URL をパブリック OIDC エンドポイントとして使用します。 -
または、
ccoctl
ユーティリティーで OIDC 設定をプライベート S3 バケットに保存し、そのバケットに、パブリック CloudFront 配布 URL を介して IAM ID プロバイダーからアクセスすることもできます。
19.5.1.2. AWS コンポーネントのシークレット形式
AWS Security Token Service (STS) で手動モードを使用すると、個々の OpenShift Container Platform コンポーネントに提供される AWS 認証情報の内容が変更されます。次のシークレット形式を比較してください。
長期認証情報を使用した AWS シークレット形式
apiVersion: v1 kind: Secret metadata: namespace: <target_namespace> 1 name: <target_secret_name> 2 data: aws_access_key_id: <base64_encoded_access_key_id> aws_secret_access_key: <base64_encoded_secret_access_key>
AWS STS を使用した AWS シークレット形式
apiVersion: v1 kind: Secret metadata: namespace: <target_namespace> 1 name: <target_secret_name> 2 stringData: credentials: |- [default] sts_regional_endpoints = regional role_name: <operator_role_name> 3 web_identity_token_file: <path_to_token> 4
19.5.1.3. AWS コンポーネントのシークレット権限の要件
OpenShift Container Platform コンポーネントには次の権限が必要です。これらの値は、各コンポーネントの CredentialsRequest
カスタムリソース (CR) にあります。
これらの権限はすべてのリソースに適用されます。特に指定しない限り、これらのアクセス許可には要求条件はありません。
コンポーネント | カスタムリソース | サービスに必要な権限 |
---|---|---|
Cluster CAPI Operator |
| EC2
Elastic load balancing
Identity and Access Management (IAM)
キー管理サービス (KMS)
|
Machine API Operator |
| EC2
Elastic load balancing
Identity and Access Management (IAM)
キー管理サービス (KMS)
|
Cloud Credential Operator |
| Identity and Access Management (IAM)
|
Cluster Image Registry Operator |
| S3
|
Ingress Operator |
| Elastic load balancing
Route 53
Tag
セキュリティートークンサービス (STS)
|
Cluster Network Operator |
| EC2
|
AWS Elastic Block Store CSI Driver Operator |
| EC2
キー管理サービス (KMS)
|
-
リクエスト条件:
kms:GrantIsForAWSResource: true
19.5.1.4. AWS STS による認証に対する OLM 管理の Operator サポート
OpenShift Container Platform クラスターコンポーネントに加えて、AWS クラスター上の Operator Lifecycle Manager (OLM) によって管理される一部の Operator は、STS で手動モードを使用できます。これらの Operator は、クラスターの外部で管理される限定された権限の短期認証情報を使用して認証します。Operator が AWS STS による認証をサポートしているかどうかを確認するには、OperatorHub の Operator の説明を参照してください。
19.5.2. GCP Workload Identity
GCP Workload Identity を使用した手動モードでは、個々の OpenShift Container Platform クラスターコンポーネントは GCP Workload Identity プロバイダーを使用して、コンポーネントが短期間の限定された権限の認証情報を使用して GCP サービスアカウントを偽装できるようにします。
19.5.2.1. GCP Workload Identity 認証プロセス
新しい認証情報と更新された認証情報の要求は、適切に設定された OpenID Connect (OIDC) ID プロバイダーと IAM サービスアカウントを組み合わせて使用することで自動化されます。GCP によって信頼されているサービスアカウントトークンは、OpenShift Container Platform によって署名されており、Pod に展開して認証に使用できます。トークンは 1 時間後に更新されます。
次の図は、GCP Workload Identity を使用する場合の GCP と OpenShift Container Platform クラスター間の認証フローを詳しく示しています。
図19.3 GCP Workload ID の認証フロー
19.5.2.2. GCP コンポーネントのシークレット形式
GCP Workload Identity で手動モードを使用すると、個々の OpenShift Container Platform コンポーネントに提供される GCP クレデンシャルのコンテンツが変更されます。次のシークレットのコンテンツを比較してください。
GCP シークレットフォーマット
apiVersion: v1 kind: Secret metadata: namespace: <target_namespace> 1 name: <target_secret_name> 2 data: service_account.json: <service_account> 3
長期間有効なクレデンシャルを使用した Base64 でエンコードされた service_account.json
ファイルのコンテンツ
{ "type": "service_account", 1 "project_id": "<project_id>", "private_key_id": "<private_key_id>", "private_key": "<private_key>", 2 "client_email": "<client_email_address>", "client_id": "<client_id>", "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/<client_email_address>" }
GCP Workload Identity を使用した Base64 でエンコードされた service_account.json
ファイルのコンテンツ
{ "type": "external_account", 1 "audience": "//iam.googleapis.com/projects/123456789/locations/global/workloadIdentityPools/test-pool/providers/test-provider", 2 "subject_token_type": "urn:ietf:params:oauth:token-type:jwt", "token_url": "https://sts.googleapis.com/v1/token", "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<client_email_address>:generateAccessToken", 3 "credential_source": { "file": "<path_to_token>", 4 "format": { "type": "text" } } }
19.5.3. Microsoft Entra Workload ID
Microsoft Entra Workload ID を使用した手動モードでは、個々の OpenShift Container Platform クラスターコンポーネントは、Workload ID プロバイダーを使用して、コンポーネントに短期セキュリティー認証情報を割り当てます。
19.5.3.1. Microsoft Entra Workload ID 認証プロセス
次の図は、Microsoft Entra Workload ID を使用する場合の Azure と OpenShift Container Platform クラスター間の認証フローの詳細を示しています。
図19.4 ワークロード ID 認証フロー
19.5.3.2. Azure コンポーネントのシークレット形式
Microsoft Entra Workload ID で手動モードを使用すると、個々の OpenShift Container Platform コンポーネントに提供される Azure 認証情報の内容が変更されます。次のシークレット形式を比較してください。
長期認証情報を使用した Azure シークレット形式
apiVersion: v1 kind: Secret metadata: namespace: <target_namespace> 1 name: <target_secret_name> 2 data: azure_client_id: <client_id> 3 azure_client_secret: <client_secret> 4 azure_region: <region> azure_resource_prefix: <resource_group_prefix> 5 azure_resourcegroup: <resource_group_prefix>-rg 6 azure_subscription_id: <subscription_id> azure_tenant_id: <tenant_id> type: Opaque
Microsoft Entra Workload ID を使用した Azure シークレット形式
apiVersion: v1 kind: Secret metadata: namespace: <target_namespace> 1 name: <target_secret_name> 2 data: azure_client_id: <client_id> 3 azure_federated_token_file: <path_to_token_file> 4 azure_region: <region> azure_subscription_id: <subscription_id> azure_tenant_id: <tenant_id> type: Opaque
19.5.3.3. Azure コンポーネントのシークレット権限の要件
OpenShift Container Platform コンポーネントには次の権限が必要です。これらの値は、各コンポーネントの CredentialsRequest
カスタムリソース (CR) にあります。
コンポーネント | カスタムリソース | サービスに必要な権限 |
---|---|---|
Cloud Controller Manager Operator |
|
|
Cluster CAPI Operator |
|
ロール: |
Machine API Operator |
|
|
Cluster Image Registry Operator |
| データ権限
一般的な権限
|
Ingress Operator |
|
|
Cluster Network Operator |
|
|
Azure File CSI Driver Operator |
|
|
Azure Disk CSI Driver Operator |
|
|
- このコンポーネントには、一連の権限ではなくロールが必要です。