19.3. 使用 passthrough 模式
Amazon Web Services(AWS)、Microsoft Azure、Google Cloud Platform(GCP)、Red Hat OpenStack Platform(RHOSP)、Red Hat Virtualization(RHV)和 VMware vSphere 支持 passthrough 模式。
在 passthrough 模式中,Cloud Credential Operator(CCO)将提供的云凭证传递给请求云凭证的组件。凭证必须具有执行安装的权限,并可以完成集群中组件所需的操作,但并不需要可以创建新凭证的权限。CCO 不会尝试在 passthrough 模式中创建额外的有限范围凭证。
手动模式是唯一支持 Microsoft Azure Stack Hub 的 CCO 配置。
19.3.1. passthrough 模式权限要求
在使用 CCO 的 passthrough 模式时,请确保您提供的凭证满足运行或安装 OpenShift Container Platform 的云要求。如果提供的凭证由 CCO 传递给一个创建 CredentialsRequest
CR 的组件,则该组件会在尝试调用没有权限的 API 时报告错误。
19.3.1.1. Amazon Web Services(AWS)权限
您在 AWS 中提供的 passthrough 模式的凭证必须具有您正在运行或安装的 OpenShift Container Platform 版本所需的所有 credentialsRequest
CR 的所有请求权限。
要找到所需的 CredentialsRequest
CR,请参阅为 AWS 手动创建 IAM。
19.3.1.2. Microsoft Azure 权限
您在 Azure 中提供的 passthrough 模式的凭证必须具有您正在运行或安装的 OpenShift Container Platform 版本所需的所有 credentialsRequest
CR 的所有请求权限。
要找到所需的 CredentialsRequest
CR,请参阅为 Azure 手动创建 IAM。
19.3.1.3. Google Cloud Platform(GCP)权限
您在 GCP 中提供的 passthrough 模式的凭证必须具有您正在运行或安装的 OpenShift Container Platform 版本所需的所有 credentialsRequest
CR 的所有请求权限。
要找到所需的 CredentialsRequest
CR,请参阅为 GCP 手动创建 IAM。
19.3.1.4. Red Hat OpenStack Platform(RHOSP)权限
要在 RHOSP 上安装 OpenShift Container Platform 集群,CCO 需要具有 member
用户角色权限的凭证。
19.3.1.5. Red Hat Virtualization(RHV)权限
要在 RHV 上安装 OpenShift Container Platform 集群,CCO 需要具有以下权限的凭证:
-
DiskOperator
-
DiskCreator
-
UserTemplateBasedVm
-
TemplateOwner
-
TemplateCreator
-
在用于 OpenShift Container Platform 部署的特定集群中的
ClusterAdmin
19.3.1.6. VMware vSphere 权限
要在 VMware vSphere 上安装 OpenShift Container Platform 集群,CCO 需要具有以下 vSphere 权限的凭证:
类别 | 权限 |
---|---|
数据存储 | 分配空间 |
目录 | Create folder、Delete folder |
vSphere 标记 | 所有权限 |
网络 | 分配网络 |
资源 | 为资源池分配虚拟机 |
配置集驱动的存储 | 所有权限 |
vApp | 所有权限 |
虚拟机器 | 所有权限 |
19.3.2. 管理凭证 root secret 格式
每个云供应商都使用 kube-system
命名空间中的一个凭证 root secret,用于满足所有凭证请求并创建它们对应的 secret。这可以通过 mint 新凭证使用 mint 模式 完成,或使用 passthrough 模式 复制凭证 root secret。
secret 的格式因云而异,也用于每个 CredentialsRequest
secret。
Amazon Web Services(AWS)secret 格式
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 secret 格式
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 中,凭证 secret 格式包括两个必须包含集群基础架构 ID 的属性,每个集群安装随机生成。该值可在运行创建清单后找到:
$ cat .openshift_install_state.json | jq '."*installconfig.ClusterID".InfraID' -r
输出示例
mycluster-2mpcn
这个值将在 secret 数据中使用,如下所示:
azure_resource_prefix: mycluster-2mpcn azure_resourcegroup: mycluster-2mpcn-rg
Google Cloud Platform(GCP)secret 格式
apiVersion: v1 kind: Secret metadata: namespace: kube-system name: gcp-credentials stringData: service_account.json: <base64-encoded_service_account>
Red Hat OpenStack Platform (RHOSP) secret 格式
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) secret 格式
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 secret 格式
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>
19.3.3. passthrough 模式凭证维护
如果 CredentialsRequest
CR 随着集群升级而变化,您必须手动更新 passthrough 模式凭证以满足要求。为了避免升级过程中出现凭证问题,请在升级前检查发行镜像中的 CredentialsRequest
CR。要找到云供应商所需的 CredentialsRequest
CR,请参阅为 AWS、Azure 或 GCP 手动创建 IAM。
19.3.3.1. 手动轮转云供应商凭证
如果因为某种原因更改了云供应商凭证,您必须手动更新 Cloud Credential Operator(CCO)用来管理云供应商凭证的 secret。
轮转云凭证的过程取决于 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 页面的表中,找到您的云供应商的 root secret。
平台 Secret 名称 AWS
aws-creds
Azure
azure-credentials
GCP
gcp-credentials
RHOSP
openstack-credentials
RHV
ovirt-credentials
VMware vSphere
vsphere-creds
- 点击与 secret 相同的行 中的 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 字段的内容已改变。
19.3.4. 在安装后减少权限
在使用 passthrough 模式时,每个组件都有相同的权限供所有其他组件使用。如果您在安装后不减少权限,则所有组件都有运行安装程序所需的广泛权限。
安装后,您可以将凭证的权限减少到仅限运行集群所需的权限,这由您正在使用的 OpenShift Container Platform 版本的发行镜像中的 CredentialsRequest
CR 定义。
要找到 AWS、Azure 或 GCP 所需的 CredentialsRequest
CR,并了解如何更改 CCO 所用权限,请参阅为 AWS、Azure 或 GCP 手动创建 IAM。