×
组件的短期凭据手动模式
在安装过程中，您可以将云凭据操作符 (CCO) 配置为手动模式，并使用 CCO 实用程序 (ccoctl) 为在 OpenShift Container Platform 集群外部创建和管理的各个组件实现短期安全凭据。
|
此凭据策略仅支持 Amazon Web Services (AWS)、Google Cloud Platform (GCP) 和全球 Microsoft Azure。 对于 AWS 和 GCP 集群，您必须在安装新的 OpenShift Container Platform 集群期间将集群配置为使用此策略。您无法将使用不同凭据策略的现有 AWS 或 GCP 集群配置为使用此功能。 如果您在安装期间未将 Azure 集群配置为使用 Microsoft Entra 工作负载 ID，则可以在现有集群上启用此身份验证方法。 |
云提供商在其此身份验证方法的实现中使用不同的术语。
| 云提供商 | 提供商命名法 |
|---|---|
Amazon Web Services (AWS) |
AWS 安全令牌服务 (STS) |
Google Cloud Platform (GCP) |
GCP 工作负载身份 |
全球 Microsoft Azure |
Microsoft Entra 工作负载 ID |
AWS 安全令牌服务
在使用安全令牌服务 (STS) 的手动模式下，各个 OpenShift Container Platform 集群组件使用 AWS STS 为组件分配 IAM 角色，这些角色提供短期、有限权限的安全凭据。这些凭据与对每个进行 AWS API 调用的组件特定的 IAM 角色相关联。
其他资源
AWS 安全令牌服务身份验证流程
AWS 安全令牌服务 (STS) 和AssumeRole API 操作允许 Pod 检索由 IAM 角色策略定义的访问密钥。
OpenShift Container Platform 集群包含一个 Kubernetes 服务帐户签名服务。此服务使用私钥来签署服务帐户 JSON 网络令牌 (JWT)。需要服务帐户令牌的 Pod 通过 Pod 规范请求一个令牌。当 Pod 被创建并分配到节点时，节点从服务帐户签名服务检索已签名的服务帐户并将其挂载到 Pod 上。
使用 STS 的集群在其 Kubernetes 配置密钥中包含 IAM 角色 ID。工作负载承担此 IAM 角色 ID 的身份。签发给工作负载的已签名服务帐户令牌与 AWS 中的配置一致，这允许 AWS STS 向工作负载授予指定 IAM 角色的访问密钥。
AWS STS 仅为包含满足以下条件的服务帐户令牌的请求授予访问密钥
-
令牌名称和命名空间与服务帐户名称和命名空间匹配。
-
令牌由与公钥匹配的密钥签名。
集群使用的服务帐户签名密钥的公钥对存储在 AWS S3 存储桶中。AWS STS 联合身份验证验证服务帐户令牌签名是否与存储在 S3 存储桶中的公钥一致。
AWS STS 的身份验证流程
下图说明了使用 AWS STS 时 AWS 和 OpenShift Container Platform 集群之间的身份验证流程。
-
令牌签名是 OpenShift Container Platform 集群上的 Kubernetes 服务帐户签名服务。
-
Pod 中的Kubernetes 服务帐户是已签名的服务帐户令牌。
图 1. AWS 安全令牌服务身份验证流程
使用适当配置的 AWS IAM OpenID Connect (OIDC) 身份提供程序结合 AWS IAM 角色，可以自动执行对新凭据和刷新凭据的请求。AWS IAM 信任的服务帐户令牌由 OpenShift Container Platform 签名，可以投影到 Pod 中并用于身份验证。
AWS STS 的令牌刷新
Pod 使用的已签名服务帐户令牌会在一段时间后过期。对于使用 AWS STS 的集群，此时间段为 3600 秒，即一小时。
分配 Pod 的节点上的 kubelet 会确保令牌被刷新。当令牌的剩余有效时间少于其生存时间的 80% 时，kubelet 会尝试轮换令牌。
AWS STS 的 OpenID Connect 要求
您可以将 OIDC 配置的加密密钥的公共部分存储在公共或私有 S3 存储桶中。
OIDC 规范要求使用 HTTPS。AWS 服务需要一个公共端点来以 JSON 网络密钥集 (JWKS) 公钥的形式公开 OIDC 文档。这允许 AWS 服务验证 Kubernetes 签名的绑定令牌并确定是否信任证书。因此，这两个 S3 存储桶选项都需要一个公共 HTTPS 端点，并且不支持私有端点。
要使用 AWS STS，AWS STS 服务的公共 AWS 主干必须能够与公共 S3 存储桶或具有公共 CloudFront 端点的私有 S3 存储桶通信。您可以在安装过程中处理 CredentialsRequest 对象时选择要使用哪种类型的存储桶。
-
默认情况下，CCO 实用程序 (
ccoctl) 将 OIDC 配置文件存储在公共 S3 存储桶中，并将 S3 URL 用作公共 OIDC 端点。 -
或者，您可以让
ccoctl实用程序将 OIDC 配置存储在私有 S3 存储桶中，IAM 身份提供程序通过公共 CloudFront 分发 URL 访问该存储桶。
AWS 组件密钥格式
在手动模式下使用 AWS 安全令牌服务 (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>| 1 | 组件的命名空间。 |
| 2 | 组件密钥的名称。 |
使用 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)| 1 | 组件的命名空间。 |
| 2 | 组件密钥的名称。 |
| 3 | 组件的 IAM 角色。 |
| 4 | Pod 内服务帐户令牌的路径。按照惯例，对于 OpenShift Container Platform 组件，这是/var/run/secrets/openshift/serviceaccount/token。 |
AWS 组件密钥权限要求
OpenShift Container Platform 组件需要以下权限。这些值位于每个组件的 CredentialsRequest 自定义资源 (CR) 中。
|
这些权限适用于所有资源。除非另有说明，否则这些权限没有任何请求条件。 |
| 组件 | 自定义资源 | 服务所需的权限 |
|---|---|---|
集群 CAPI 操作符 |
|
EC2
弹性负载均衡
身份和访问管理 (IAM)
密钥管理服务 (KMS)
|
机器 API 操作符 |
|
EC2
弹性负载均衡
身份和访问管理 (IAM)
密钥管理服务 (KMS)
|
云凭据操作符 |
|
身份和访问管理 (IAM)
|
集群镜像注册表操作符 |
|
S3
|
入口控制器 (Ingress Operator) |
|
弹性负载均衡
Route 53
标签 (Tag)
安全令牌服务 (Security Token Service, STS)
|
集群网络操作符 (Cluster Network Operator) |
|
EC2
|
AWS Elastic Block Store CSI驱动程序操作符 |
|
EC2
密钥管理服务 (KMS)
|
-
请求条件：
kms:GrantIsForAWSResource: true
GCP 工作负载身份
在使用 GCP 工作负载身份的手动模式下，各个 OpenShift Container Platform 集群组件使用 GCP 工作负载身份提供程序，允许组件使用短期、特权有限的凭据模拟 GCP 服务帐户。
其他资源
GCP 工作负载身份验证流程
对新凭据和刷新凭据的请求通过使用正确配置的 OpenID Connect (OIDC) 身份提供程序与 IAM 服务帐户相结合来自动完成。GCP 信任的服务帐户令牌由 OpenShift Container Platform 签名，可以投影到 Pod 中并用于身份验证。令牌每小时刷新一次。
下图详细说明了使用 GCP 工作负载身份时 GCP 和 OpenShift Container Platform 集群之间的身份验证流程。
图 2. GCP 工作负载身份验证流程
GCP 组件密钥格式
使用 GCP 工作负载身份的手动模式会更改提供给各个 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)| 1 | 组件的命名空间。 |
| 2 | 组件密钥的名称。 |
| 3 | Base64 编码的服务帐户。 |
使用长期凭据的 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://127.0.0.1/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>"
}| 1 | 凭据类型为 service_account。 |
| 2 | 用于向 GCP 进行身份验证的私有 RSA 密钥。此密钥必须保持安全，并且不会轮换。 |
使用 GCP 工作负载身份的 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"
}
}
}| 1 | 凭据类型为 external_account。 |
| 2 | 目标受众是 GCP 工作负载身份提供程序。 |
| 3 | 可以使用这些凭据模拟的服务帐户的资源 URL。 |
| 4 | Pod 内服务帐户令牌的路径。按照惯例，对于 OpenShift Container Platform 组件，这是/var/run/secrets/openshift/serviceaccount/token。 |
OLM 管理的操作符对使用 GCP 工作负载身份进行身份验证的支持
在 GCP 集群上由操作符生命周期管理器 (OLM) 管理的某些操作符可以使用 GCP 工作负载身份的手动模式。这些操作符使用在集群外部管理的特权有限的短期凭据进行身份验证。要确定操作符是否支持使用 GCP 工作负载身份进行身份验证，请参阅 OperatorHub 中的操作符说明。
Microsoft Entra 工作负载 ID
在使用 Microsoft Entra 工作负载 ID 的手动模式下，各个 OpenShift Container Platform 集群组件使用工作负载 ID 提供程序为组件分配短期安全凭据。
Microsoft Entra 工作负载 ID 身份验证流程
下图详细说明了使用 Microsoft Entra 工作负载 ID 时 Azure 和 OpenShift Container Platform 集群之间的身份验证流程。
图 3. 工作负载 ID 身份验证流程
Azure 组件密钥格式
使用 Microsoft Entra 工作负载 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| 1 | 组件的命名空间。 |
| 2 | 组件密钥的名称。 |
| 3 | 组件用于进行身份验证的 Microsoft Entra ID 身份的客户端 ID。 |
| 4 | 用于针对 <client_id> 身份对 Microsoft Entra ID 进行身份验证的组件密钥。 |
| 5 | 资源组前缀。 |
| 6 | 资源组。此值由 <resource_group_prefix> 和后缀 -rg 组成。 |
使用 Microsoft Entra 工作负载 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| 1 | 组件的命名空间。 |
| 2 | 组件密钥的名称。 |
| 3 | 组件用于进行身份验证的用户分配的托管身份的客户端 ID。 |
| 4 | 已安装的服务帐户令牌文件的路径。 |
Azure 组件密钥权限要求
OpenShift Container Platform 组件需要以下权限。这些值位于每个组件的 CredentialsRequest 自定义资源 (CR) 中。
| 组件 | 自定义资源 | 服务所需的权限 |
|---|---|---|
云控制器管理器操作符 (Cloud Controller Manager Operator) |
|
|
集群 CAPI 操作符 |
|
角色： |
机器 API 操作符 |
|
|
集群镜像注册表操作符 |
|
数据权限 (Data permissions)
常规权限 (General permissions)
|
入口控制器 (Ingress Operator) |
|
|
集群网络操作符 (Cluster Network Operator) |
|
|
Azure File CSI驱动程序操作符 |
|
|
Azure Disk CSI驱动程序操作符 |
|
|
-
此组件需要角色而不是一组权限。