OpenShift文档正在迁移，很快将只在docs.redhat.com（所有Red Hat产品文档的中心）提供。立即体验新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

教程：ROSA 与 AWS STS 解释

编辑

本教程概述了允许 Red Hat OpenShift Service on AWS (ROSA) 与用户 Amazon Web Service (AWS) 帐户中的资源交互的两种选项。它详细介绍了使用安全令牌服务 (STS) 的 ROSA 使用的组件和流程以获取必要的凭据。它还回顾了为什么使用 STS 的 ROSA 是更安全、更优选的方法。

当前内容涵盖使用 AWS STS 的 ROSA Classic。对于使用 AWS STS 的托管控制平面 (HCP) 的 ROSA，请参见 AWS STS 和使用 HCP 的 ROSA 解释。

本教程将

  • 列举两种部署选项

    • 使用 IAM 用户的 ROSA

    • 使用 STS 的 ROSA

  • 解释这两种选项之间的区别

  • 解释为什么使用 STS 的 ROSA 更安全且是首选选项

  • 解释使用 STS 的 ROSA 的工作原理

部署 ROSA 的不同凭证方法

作为 ROSA 的一部分，Red Hat 管理您 AWS 帐户中的基础设施资源，并且必须授予其必要的权限。目前有两种支持的方法可以授予这些权限

  • 使用具有 AdministratorAccess 策略的静态 IAM 用户凭据

    在本教程中，这被称为“使用 IAM 用户的 ROSA”。这不是首选的凭证方法。

  • 使用 AWS STS 和短期动态令牌

    在本教程中，这被称为“使用 STS 的 ROSA”。这是首选的凭证方法。

编辑

使用 IAM 用户的 ROSA

ROSA 首次发布时，唯一的方法是使用 IAM 用户的 ROSA。此方法授予具有 AdministratorAccess 策略的 IAM 用户完全访问权限，以创建使用 ROSA 的 AWS 帐户中必要的资源。然后，集群可以根据需要创建和扩展其凭据。

使用 STS 的 ROSA

使用 STS 的 ROSA 向用户授予对您 AWS 帐户中资源的有限、短期访问权限。STS 方法使用预定义的角色和策略向 IAM 用户或经过身份验证的联合用户授予临时、最小权限的权限。凭据通常在请求后一小时过期。过期后，AWS 将不再识别它们，并且不再拥有通过使用它们进行的 API 请求的帐户访问权限。有关更多信息，请参阅 AWS 文档。虽然目前启用使用 IAM 用户的 ROSA 和使用 STS 的 ROSA，但使用 STS 的 ROSA 是首选和推荐的选项。

使用 STS 的 ROSA 安全性

几个关键组件使使用 STS 的 ROSA 比使用 IAM 用户的 ROSA 更安全

  • 用户提前创建的一组明确且有限的角色和策略。用户知道每个请求的权限和使用的每个角色。

  • 服务无法执行这些权限之外的任何操作。

  • 每当服务需要执行操作时，它都会获取在一小时或更短时间内过期的凭据。这意味着无需轮换或撤销凭据。此外，凭据过期降低了凭据泄漏和重复使用的风险。

AWS STS 解释

ROSA 使用 AWS STS 向特定和隔离的 IAM 角色授予具有短期安全凭据的最小权限权限。凭据与对进行 AWS API 调用的每个组件和集群特定的 IAM 角色相关联。此方法符合云服务资源管理中最小权限和安全实践的原则。ROSA 命令行界面 (CLI) 工具管理为唯一任务分配的 STS 角色和策略，并在作为 OpenShift 功能的一部分对 AWS 资源采取行动。

必须为每个 ROSA 集群创建 STS 角色和策略。为了简化此过程，安装工具提供创建角色作为策略所需的所有命令和文件，以及允许 CLI 自动创建角色和策略的选项。有关不同--mode选项的更多信息，请参见 使用自定义项创建使用 STS 的 ROSA 集群。

使用 STS 的 ROSA 的特定组件

  • AWS 基础设施 - 这提供了集群所需的基础设施。它包含实际的 EC2 实例、存储和网络组件。请参阅 AWS 计算类型，了解受支持的计算节点实例类型，以及 预置的 AWS 基础设施，了解控制平面和基础设施节点配置。

  • AWS STS - 请参见上文的凭据方法部分。

  • 开放ID连接 (OIDC) - 这为集群操作员提供了一种机制，用于通过AWS进行身份验证，通过信任策略承担集群角色，并从STS获取临时凭据以进行所需的API调用。

  • 角色和策略 - 角色和策略是使用STS的ROSA和使用IAM用户的ROSA之间的主要区别之一。对于使用STS的ROSA，ROSA使用的角色和策略分为帐户范围的角色和策略以及操作员角色和策略。

    策略决定每个角色允许的操作。有关各个角色和策略的更多详细信息，请参见关于使用STS的ROSA集群的IAM资源。

    • 帐户范围的角色包括：

      • ManagedOpenShift-Installer-Role

      • ManagedOpenShift-ControlPlane-Role

      • ManagedOpenShift-Worker-Role

      • ManagedOpenShift-Support-Role

    • 帐户范围的策略包括：

      • ManagedOpenShift-Installer-Role-Policy

      • ManagedOpenShift-ControlPlane-Role-Policy

      • ManagedOpenShift-Worker-Role-Policy

      • ManagedOpenShift-Support-Role-Policy

      • ManagedOpenShift-openshift-ingress-operator-cloud-credentials [1]

      • ManagedOpenShift-openshift-cluster-csi-drivers-ebs-cloud-credent [1]

      • ManagedOpenShift-openshift-cloud-network-config-controller-cloud [1]

      • ManagedOpenShift-openshift-machine-api-aws-cloud-credentials [1]

      • ManagedOpenShift-openshift-cloud-credential-operator-cloud-crede [1]

      • ManagedOpenShift-openshift-image-registry-installer-cloud-creden [1]

        1. 此策略由下面列出的集群操作员角色使用。操作员角色在第二步创建，因为它们依赖于现有的集群名称，并且不能与帐户范围的角色同时创建。

    • 操作员角色包括：

      • <集群名称>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent

      • <集群名称>-xxxx-openshift-cloud-network-config-controller-cloud

      • <集群名称>-xxxx-openshift-machine-api-aws-cloud-credentials

      • <集群名称>-xxxx-openshift-cloud-credential-operator-cloud-crede

      • <集群名称>-xxxx-openshift-image-registry-installer-cloud-creden

      • <集群名称>-xxxx-openshift-ingress-operator-cloud-credentials

    • 为每个帐户范围的角色和操作员角色创建信任策略。

部署ROSA STS集群

您无需从头开始创建以下步骤中列出的资源。ROSA CLI会为您创建所需的JSON文件，并输出您需要的命令。如果需要，ROSA CLI还可以更进一步，为您运行这些命令。

部署使用STS的ROSA集群的步骤：

  1. 创建帐户范围的角色和策略。

  2. 将权限策略分配给相应的帐户范围的角色。

  3. 创建集群。

  4. 创建操作员角色和策略。

  5. 将权限策略分配给相应的操作员角色。

  6. 创建OIDC提供程序。

角色和策略可以由ROSA CLI自动创建，也可以通过在ROSA CLI中使用--mode manual或--mode auto标志手动创建。有关部署的更多详细信息，请参见创建具有自定义设置的集群或部署集群教程。

使用STS的ROSA工作流程

用户创建所需的帐户范围的角色和帐户范围的策略。有关更多信息，请参见本教程中的组件部分。在角色创建过程中，会创建一个称为跨帐户信任策略的信任策略，该策略允许Red Hat拥有的角色承担这些角色。还会为EC2服务创建信任策略，允许EC2实例上的工作负载承担角色并获取凭据。然后，用户可以将相应的权限策略分配给每个角色。

创建帐户范围的角色和策略后，用户可以创建集群。一旦启动集群创建，就会创建操作员角色，以便集群操作员可以进行AWS API调用。然后，这些角色将被分配给之前创建的相应权限策略和与OIDC提供程序的信任策略。操作员角色与帐户范围的角色不同，因为它们最终代表需要访问AWS资源的Pod。由于用户无法将IAM角色附加到Pod，因此他们必须与OIDC提供程序创建信任策略，以便操作员（因此是Pod）可以访问他们所需的资源。

一旦用户将角色分配给相应的策略权限，最后一步就是创建OIDC提供程序。

cloud experts sts explained creation flow

当需要新角色时，当前使用Red Hat角色的工作负载将在AWS账户中承担该角色，从AWS STS获取临时凭据，并开始使用客户AWS账户中的API调用执行操作（由承担的角色的权限策略允许）。凭据是临时的，最长持续时间为一小时。

cloud experts sts explained highlevel

整个工作流程如下图所示

cloud experts sts explained entire flow

操作员使用以下流程来获取执行其任务所需的凭据。每个操作员都被分配了一个操作员角色、一个权限策略和一个与OIDC提供程序的信任策略。操作员将通过将包含角色和令牌文件 (web_identity_token_file) 的JSON Web令牌传递给OIDC提供程序来承担该角色，然后OIDC提供程序将使用公钥对签名密钥进行身份验证。公钥在集群创建期间创建并存储在S3存储桶中。然后，操作员确认签名令牌文件中的主题与角色信任策略中的角色匹配，这确保OIDC提供程序只能获取允许的角色。然后，OIDC提供程序将临时凭据返回给操作员，以便操作员可以进行AWS API调用。有关可视化表示，请参见下文

cloud experts sts explained oidc op roles

使用STS的ROSA用例

在集群安装时创建节点

Red Hat安装程序使用RH-Managed-OpenShift-Installer角色和信任策略来承担客户帐户中的Managed-OpenShift-Installer-Role角色。此过程将从AWS STS返回临时凭据。安装程序开始使用刚刚从STS接收到的临时凭据进行所需的API调用。安装程序在AWS中创建所需的 基础架构。凭据在一小时内过期，安装程序不再访问客户的帐户。

同样的过程也适用于支持案例。在支持案例中，Red Hat站点可靠性工程师 (SRE) 将替换安装程序。

扩展集群

machine-api-operator 使用AssumeRoleWithWebIdentity 来承担machine-api-aws-cloud-credentials角色。这将启动集群操作员接收凭据的序列。machine-api-operator角色现在可以进行相关的API调用，以向集群添加更多EC2实例。