7.3. 为 GCP 手动创建 IAM


在无法访问云身份和访问管理(IAM)API 的环境中,或者管理员更不希望将管理员级别的凭证 secret 存储在集群 kube-system 命名空间中,您可以在安装集群前将 Cloud Credential Operator(CCO)放入手动模式。

7.3.1. 在 kube-system 项目中存储管理员级别的 secret 的替代方案

Cloud Credential Operator(CCO)将云供应商凭证作为 Kubernetes 自定义资源定义(CRD)进行管理。您可以通过在 install-config.yaml 文件中为 credentialsMode 参数设置不同的值,将 CCO 配置为满足机构的安全要求。

如果您不希望在集群 kube-system 项目中存储管理员级别的凭证 secret,您可以在安装 OpenShift Container Platform 时选择以下选项之一:

  • 手动管理云凭证:

    您可以将 CCO 的 credentialsMode 参数设置为 Manual 以手动管理云凭证。使用手动模式可允许每个集群组件只拥有所需的权限,而无需在集群中存储管理员级别的凭证。如果您的环境没有连接到云供应商公共 IAM 端点,您还可以使用此模式。但是,每次升级都必须手动将权限与新发行镜像协调。您还必须手动为每个请求它们的组件提供凭证。

  • 使用 mint 模式安装 OpenShift Container Platform 后删除管理员级别的凭证 secret

    如果您使用 CCO,并将 credentialsMode 参数设置为 Mint,您可以在安装 OpenShift Container Platform 后删除或轮转管理员级别的凭证。Mint 模式是 CCO 的默认配置。这个选项需要在安装过程中存在管理员级别的凭证。在安装过程中使用管理员级别的凭证来最小化授予某些权限的其他凭证。原始凭证 secret 不会永久存储在集群中。

注意

在非 z-stream 升级前,您必须使用管理员级别的凭证重新恢复凭证 secret。如果没有凭证,则可能会阻止升级。

有关所有可用 CCO 凭证模式及其支持的平台的详细信息,请参阅 关于 Cloud Credential Operator

7.3.2. 手动创建 IAM

在无法访问云身份和访问管理(IAM)API 的环境中,或者管理员更不希望将管理员级别的凭证 secret 存储在集群 kube-system 命名空间中时,可以在安装前将 Cloud Credential Operator(CCO)放入手动模式。

流程

  1. 运行以下命令,切换到包含安装程序的目录并创建 install-config.yaml 文件:

    $ openshift-install create install-config --dir <installation_directory>

    其中 <installation_directory> 是安装程序在其中创建文件的目录。

  2. 编辑 install-config.yaml 配置文件,使其包含将 credentialsMode 参数设置为 Manual

    install-config.yaml 配置文件示例

    apiVersion: v1
    baseDomain: cluster1.example.com
    credentialsMode: Manual 1
    compute:
    - architecture: amd64
      hyperthreading: Enabled
    ...

    1
    添加这一行将 credentialsMode 参数设置为 Manual
  3. 要生成清单,请在包含安装程序的目录中运行以下命令:

    $ openshift-install create manifests --dir <installation_directory>

    其中 <installation_directory> 是安装程序在其中创建文件的目录。

  4. 在包含安装程序的目录中,运行以下命令来获取构建 openshift-install 二进制文件的 OpenShift Container Platform 发行镜像的详情:

    $ openshift-install version

    输出示例

    release image quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64

  5. 运行以下命令,找到此发行版本镜像中的所有 CredentialsRequest 对象:

    $ oc adm release extract quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64 \
      --credentials-requests \
      --cloud=gcp

    此命令为每个 CredentialsRequest 对象创建一个 YAML 文件。

    CredentialsRequest 对象示例

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component-credentials-request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: GCPProviderSpec
        predefinedRoles:
        - roles/storage.admin
        - roles/iam.serviceAccountUser
        skipServiceCheck: true
      ...

  6. 在之前生成的 openshift-install 清单目录中为 secret 创建 YAML 文件。secret 必须使用在 spec.secretRef 中为每个 CredentialsRequest 定义的命名空间和 secret 名称存储。

    带有 secret 的 CredentialsRequest 对象示例

    apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: <component-credentials-request>
      namespace: openshift-cloud-credential-operator
      ...
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
          ...
      secretRef:
        name: <component-secret>
        namespace: <component-namespace>
      ...

    Secret 对象示例

    apiVersion: v1
    kind: Secret
    metadata:
      name: <component-secret>
      namespace: <component-namespace>
    data:
      service_account.json: <base64_encoded_gcp_service_account_file>

重要

在升级使用手动维护凭证的集群前,您必须确保 CCO 处于可升级状态。详情请参阅您的云供应商的安装内容"使用手动维护凭证对集群进行升级"部分。

7.3.3. 使用手动维护的凭证升级集群

默认情况下,带有手动维护凭证的集群的 Cloud Credential Operator(CCO)U gradable 状态为 False

  • 对于次发行版本(例如从 4.8 升级到 4.9),这个状态会阻止升级,直到您解决了任何更新的权限并 添加了 CloudCredential 资源,以指示下一版本根据需要更新权限。此注解将 Upgradable 状态更改为 True
  • 对于 z-stream 版本(例如从 4.9.0 到 4.9.1),没有添加或更改任何权限,因此不会阻止升级。

在使用手动维护凭证升级集群前,您必须为要升级到的发行镜像创建新凭证。另外,您必须检查现有凭证所需的权限,并满足新版本中这些组件的任何新权限要求。

流程

  1. 提取并检查 新版本的 CredentialsRequest 自定义资源。

    详情请参阅您的云供应商的“手动创建 IAM”部分来了解如何获取和使用您的云所需的凭证。

  2. 更新集群中手动维护的凭证:

    • 为新发行镜像添加的任何 CredentialsRequest 自定义资源创建新 secret。
    • 如果存储在 secret 中的任何现有凭证的 CredentialsRequest 自定义资源更改了其权限要求,请根据需要更新权限。
  3. 当所有 secret 都对新发行版本正确时,表示集群已准备好升级:

    1. 以具有 cluster-admin 角色的用户身份登录 OpenShift Container Platform CLI。
    2. 编辑 CloudCredential 资源,以在 metadata 字段中添加 可升级至 注解:

      $ oc edit cloudcredential cluster

      要添加的文本

      ...
        metadata:
          annotations:
            cloudcredential.openshift.io/upgradeable-to: <version_number>
      ...

      其中 <version_number> 是您要升级到的版本,格式为 x.y.z。例如,OpenShift Container Platform 4.8.2 代表 OpenShift Container Platform 4.8.2。

      添加可升级状态进行更改的注解后,可能需要几分钟时间。

  4. 验证 CCO 是否可升级:

    1. 在 Web 控制台的 Administrator 视角中,导航到 Administration Cluster Settings
    2. 要查看 CCO 状态详情,请点击 Cluster Operators 列表中的 cloud-credential
    3. 如果 Conditions 部分中的 Upgradeable 状态为 False,请验证 upgradeable-to 注解没有拼写错误。

Conditions 部分中的 Upgradeable 状态为 True 时,您可以开始 OpenShift Container Platform 升级。

:_content-type: CONCEPT

7.3.4. Mint 模式

Mint 模式是 OpenShift Container Platform 的默认 Cloud Credential Operator (CCO) 凭证模式。在这个模式中,CCO 使用提供的管理员级云凭证来运行集群。AWS 和 GCP 支持 Mint 模式。

在 mint 模式中,admin 凭证 存储在 kube-system 命名空间中,然后由 CCO 使用来处理集群中的 CredentialsRequest 对象,并为每个对象创建具有特定权限的用户。

mint 模式的好处包括:

  • 每个集群组件只有其所需的权限
  • 云凭证的自动、持续协调,包括升级可能需要的额外凭证或权限

mint 模式的一个缺点是,admin 凭证 存储到集群 kube-system secret 中。

7.3.5. 带有删除或轮转管理员级别的凭证的 Mint 模式

目前,只有 AWS 和 GCP 支持这个模式。

在这个模式中,用户使用管理员级别的凭证安装 OpenShift Container Platform,就像正常的 mint 模式一样。但是,这个过程会在安装后从集群中删除管理员级别的凭证 secret。

管理员可以让 Cloud Credential Operator 自行请求只读凭证,许它验证所有 CredentialsRequest 对象是否有其所需的权限。因此,除非需要更改内容,否则不需要管理员级别的凭证。删除关联的凭证后,可以根据需要在底层云中删除或取消激活它。

注意

在非 z-stream 升级前,您必须使用管理员级别的凭证重新恢复凭证 secret。如果没有凭证,则可能会阻止升级。

管理员级别的凭证不会永久存储在集群中。

按照以下步骤,在短时间内仍然需要集群中的管理员级别的凭证。它还需要使用每次升级的管理员级别的凭证手动重新生成 secret。

7.3.6. 后续步骤

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.