19.5. 带组件的短期凭证的手动模式
在安装过程中,您可以将 Cloud Credential Operator (CCO)配置为以手动模式运行,并使用 CCO 实用程序 (ccoctl
) 为在 OpenShift Container Platform 集群外创建和管理的独立组件实施短期安全凭证。
Amazon Web Services (AWS)、Google Cloud Platform (GCP)和全局 Microsoft Azure 支持此凭证策略。必须在安装新的 OpenShift Container Platform 集群时配置策略。您无法重新配置使用不同凭证策略的现有集群,以使用此功能。
云提供商在其实施此身份验证方法时使用不同的术语。
云供应商 | Provider nomenclature |
---|---|
Amazon Web Services (AWS) | AWS 安全令牌服务(STS) |
Google Cloud Platform (GCP) | GCP Workload Identity |
Global Microsoft Azure | Microsoft Entra Workload ID |
19.5.1. AWS 安全令牌服务
在带有安全令牌服务(STS)的手动模式中,各个 OpenShift Container Platform 集群组件使用 AWS 安全令牌服务(STS)来分配提供短期、有限权限安全凭证的组件 IAM 角色。这些凭证与特定于发布 AWS API 调用的每个组件的 IAM 角色关联。
其他资源
19.5.1.1. AWS 安全令牌服务身份验证过程
AWS 安全令牌服务(STS)和 AssumeRole
API 操作允许 pod 检索 IAM 角色策略定义的访问密钥。
OpenShift Container Platform 集群包含一个 Kubernetes 服务帐户签名服务。此服务使用私钥为服务帐户 JSON Web 令牌 (JWT) 签名。需要服务帐户令牌的 pod 通过 pod 规格请求一个。当 pod 创建并分配给节点时,节点会从服务帐户签名服务中检索签名的服务帐户,并将它挂载到 pod。
使用 STS 的集群在其 Kubernetes 配置 secret 中包含一个 IAM 角色 ID。工作负载假定此 IAM 角色 ID 的身份。向工作负载发布的已签名的服务帐户令牌与 AWS 中的配置一致,它允许 AWS STS 为工作负载授予指定 IAM 角色访问密钥。
AWS STS 仅为包含满足以下条件的服务帐户令牌的请求授予访问密钥:
- 令牌名称和命名空间与服务帐户名称和命名空间匹配。
- 令牌由与公钥匹配的密钥签名。
集群使用的服务帐户签名密钥的公钥对存储在 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 安全令牌服务身份验证流
使用适当配置的 AWS IAM OpenID Connect(OIDC)身份提供程序以及 AWS IAM 角色会自动请求新的和刷新的凭证。AWS IAM 信任的服务帐户令牌由 OpenShift Container Platform 签名,并可投射到 pod 中并用于身份验证。
19.5.1.1.2. AWS STS 的令牌刷新
pod 使用签名的服务帐户令牌在一段时间内过期。对于使用 AWS STS 的集群,这个时间段为 3600 秒,或一小时。
分配了 pod 的节点上的 kubelet,以确保刷新令牌。当令牌超过这个值的 80% 时,kubelet 会尝试轮转令牌。
19.5.1.1.3. AWS STS 的 OpenID Connect 要求
您可以在一个公共的或私有的 S3 存储中保存您的 OIDC 配置的密钥的公钥部分。
OIDC spec 需要使用 HTTPS。AWS 服务需要一个公共端点,以 JSON Web 密钥集 (JWKS) 公钥的形式公开 OIDC 文档。这允许 AWS 服务验证由 Kubernetes 签名的绑定令牌,并确定是否信任证书。因此,S3 存储桶选项都需要一个公共 HTTPS 端点和私有端点。
要使用 AWS STS,AWS STS 服务的公共 AWS 后端必须能够与公共 S3 存储桶或私有 S3 存储桶与公共 CloudFront 端点通信。您可以选择在安装过程中处理 CredentialsRequest
对象时要使用的存储桶类型:
-
默认情况下,CCO 实用程序 (
ccoctl
) 将 OIDC 配置文件存储在公共 S3 存储桶中,并使用 S3 URL 作为公共 OIDC 端点。 -
另外,您可以将
ccoctl
实用程序将 OIDC 配置存储在 IAM 身份提供程序通过一个公共 CloudFront 发行版 URL 访问的专用 S3 存储桶中。
19.5.1.2. AWS 组件 secret 格式
将手动模式与 AWS 安全令牌服务(STS)一起使用会更改提供给各个 OpenShift Container Platform 组件的 AWS 凭证的内容。比较以下 secret 格式:
使用长期凭证的 AWS secret 格式
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 secret 格式
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 组件 secret 权限要求
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
标签
安全令牌服务(STS)
|
Cluster Network Operator |
| EC2
|
AWS Elastic Block Store CSI Driver Operator |
| EC2
密钥管理服务(KMS)
|
-
请求条件:
kms:GrantIsForAWSResource: true
19.5.1.4. OLM 管理的 Operator 支持使用 AWS STS 进行身份验证
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 工作负载身份提供程序来允许组件使用短期、有限权限的凭证模拟 GCP 服务帐户。
其他资源
19.5.2.1. GCP Workload Identity 验证过程
使用正确配置的 OpenID Connect (OIDC) 身份提供程序以及 IAM 服务帐户来自动请求新的和刷新的凭证。GCP 信任的服务帐户令牌由 OpenShift Container Platform 签名,并可投射到 pod 中并用于身份验证。令牌会在一小时后刷新。
下图显示了在使用 GCP Workload Identity 时 GCP 和 OpenShift Container Platform 集群之间的身份验证流。
图 19.3. GCP Workload Identity 身份验证流
19.5.2.2. GCP 组件 secret 格式
在 GCP Workload Identity 中使用手动模式会更改提供给各个 OpenShift Container Platform 组件的 GCP 凭证的内容。比较以下 secret 内容:
GCP secret 格式
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.2.3. OLM 管理的 Operator 支持使用 GCP Workload Identity 进行身份验证
GCP 集群上的 Operator Lifecycle Manager (OLM) 管理的某些 Operator 可以在 GCP Workload Identity 中使用手动模式。这些 Operator 使用在集群外管理的有限权限短期凭证进行身份验证。要确定 Operator 支持 GCP Workload Identity 进行身份验证,请参阅 OperatorHub 中的 Operator 描述。
19.5.2.4. GCP Workload Identity 服务帐户令牌的应用程序支持
使用 Google Cloud Platform Workload Identity 的 OpenShift Container Platform 集群上的客户工作负载中的应用程序可以使用 GCP Workload Identity 进行身份验证。要将这个验证方法用于应用程序,您必须在云供应商控制台和 OpenShift Container Platform 集群中完成配置步骤。
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. Workload ID 身份验证流
19.5.3.2. Azure 组件 secret 格式
在 Microsoft Entra Workload ID 中使用手动模式会更改提供给各个 OpenShift Container Platform 组件的 Azure 凭证的内容。比较以下 secret 格式:
使用长期凭证的 Azure secret 格式
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 secret 格式
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 组件 secret 权限要求
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 |
|
|
- 此组件需要角色而不是一组权限。
19.5.3.4. OLM 管理的 Operator 支持使用 Microsoft Entra Workload ID 进行身份验证
Azure 集群上的 Operator Lifecycle Manager (OLM) 管理的某些 Operator 可以使用 Microsoft Entra Workload ID 的手动模式。这些 Operator 使用在集群外管理的短期凭证进行身份验证。要确定 Operator 是否支持使用 Workload ID 进行身份验证,请参阅 OperatorHub 中的 Operator 描述。