17.2. 教程:使用 AWS STS 的 ROSA 解释


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

注意

此内容目前涵盖使用 AWS STS 的 ROSA Classic。对于使用 AWS STS 托管 control plane (HCP)的 ROSA,请参阅 AWS STS 和使用 HCP 的 ROSA 解释

本教程将:

  • Enumerate 两个部署选项:

    • 使用 IAM 用户的 ROSA 用户
    • 使用 STS 的 ROSA
  • 解释两个选项之间的区别
  • 解释为什么使用 STS 的 ROSA 更安全和首选选项
  • 解释使用 STS 的 ROSA 的工作原理

17.2.1. 部署 ROSA 的不同凭证方法

作为 ROSA 的一部分,红帽管理 AWS 帐户中的基础架构资源,且必须授予所需的权限。目前有两种方法来授予这些权限:

  • 使用带有 AdministratorAccess 策略的静态 IAM 用户凭证

    在本教程中,这被称为 "ROSA with IAM Users"。这不是首选凭证方法。

  • 使用带有简短的动态令牌的 AWS STS

    在本教程中,这被称为 "ROSA with STS"。它是首选凭证方法。

17.2.1.1. 使用 IAM 用户的 ROSA 用户

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

17.2.1.2. 使用 STS 的 ROSA

使用 STS 的 ROSA 授予用户对 AWS 帐户中资源的有限、短期访问权限。STS 方法使用预定义的角色和策略为 IAM 用户或经过身份验证的用户授予临时的、最低特权权限。在请求后,凭据通常会在一小时后过期。过期后,AWS 不再识别它们,不再从 API 请求访问它们。如需更多信息,请参阅 AWS 文档。虽然当前启用了带有 IAM 用户和带有 STS 的 ROSA,但使用 STS 的 ROSA 是首选的和推荐选项。

17.2.2. 使用 STS 安全性的 ROSA

几个关键组件使带有 STS 的 ROSA 比使用 IAM 用户进行 ROSA 更安全:

  • 用户提前创建的明确和有限的角色和策略集合。用户知道每个请求的权限以及所使用的每个角色。
  • 该服务不能在这些权限之外执行任何操作。
  • 每当服务需要执行某个操作时,它会获取以一小时或更少形式过期的凭证。这意味着不需要轮转或撤销凭证。另外,凭证过期会降低凭证泄漏和重复使用的风险。

17.2.3. AWS STS 解释

ROSA 使用 AWS STS 为特定的和隔离的 IAM 角色,为特定的和隔离的 IAM 角色授予具有短期安全凭证的最低特权权限。凭证与特定于每个组件的 IAM 角色关联,并发出 AWS API 调用的集群。此方法与云服务资源管理中最低特权和安全实践的原则一致。ROSA 命令行界面(CLI)工具管理为唯一任务分配的 STS 角色和策略,并作为 OpenShift 功能的一部分对 AWS 资源执行操作。

必须为每个 ROSA 集群创建 STS 角色和策略。为了更容易实现这一点,安装工具提供了创建角色所需的所有命令和文件,以及一个允许 CLI 自动创建角色和策略的选项。如需有关 different- mode 选项的更多信息,请参阅使用自定义创建带有 STS 的 ROSA 集群

17.2.4. 特定于使用 STS 的 ROSA 的组件

  • AWS 基础架构 - 这提供了集群所需的基础架构。它包含实际的 EC2 实例、存储和网络组件。请参阅 AWS 计算类型,以查看计算节点支持的实例类型,以及用于 control plane 和基础架构节点配置的 置备 AWS 基础架构
  • AWS STS - 请参阅上面的凭证方法部分。
  • OpenID Connect (OIDC) - 这为集群 Operator 提供了与 AWS 进行身份验证的机制,通过信任策略假设集群角色,并从 STS 获取临时凭证来进行所需的 API 调用。
  • 角色和策略 - 角色和策略是 ROSA 使用 STS 和带有 IAM 用户的 ROSA 之间的主要区别之一。对于使用 STS 的 ROSA,ROSA 使用的角色和策略被分为集群范围的角色和策略,以及 Operator 角色和策略。

    策略决定了每个角色允许的操作。有关各个角色和策略的更多详情,请参阅使用 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. 此策略供集群 Operator 角色使用,如下所列。Operator 角色在第二个步骤中创建,因为它们依赖于现有集群名称,且无法与集群范围的角色同时创建。
    • Operator 角色是:

      • <cluster-name\>-xxxx-openshift-cluster-csi-drivers-ebs-cloud-credent
      • <cluster-name\>-xxxx-openshift-cloud-network-config-controller-cloud
      • <cluster-name\>-xxxx-openshift-machine-api-aws-cloud-credentials
      • <cluster-name\>-xxxx-openshift-cloud-credential-operator-cloud-crede
      • <cluster-name\>-xxxx-openshift-image-registry-installer-cloud-creden
      • <cluster-name\>-xxxx-openshift-ingress-operator-cloud-credentials
    • 为每个账户和 Operator 角色创建信任策略。

17.2.5. 部署 ROSA STS 集群

您不应该从头开始创建以下步骤中列出的资源。ROSA CLI 为您创建所需的 JSON 文件,并输出您需要的命令。ROSA CLI 也可以进一步执行这一步,并在需要时为您运行命令。

使用 STS 集群部署 ROSA 的步骤

  1. 创建集群范围的角色和策略。
  2. 将权限策略分配给对应的集群范围的角色。
  3. 创建集群。
  4. 创建 Operator 角色和策略。
  5. 为对应的 Operator 角色分配权限策略。
  6. 创建 OIDC 供应商。

角色和策略可由 ROSA CLI 自动创建,也可以使用 ROSA CLI 中的 --mode manual--mode auto 标志手动创建。有关部署的详情,请参阅 使用自定义创建集群部署集群指南

17.2.6. 使用 STS 工作流的 ROSA

用户创建所需的集群范围的角色和集群范围的策略。如需更多信息,请参阅本教程中的组件部分。在创建角色时,会创建一个信任策略,称为跨帐户信任策略,该策略允许红帽拥有的角色假定角色。还会为 EC2 服务创建信任策略,它允许 EC2 实例上的工作负载假定角色和获取凭据。然后,用户可以为每个角色分配对应的权限策略。

创建集群范围的角色和策略后,用户可以创建集群。启动集群创建后,会创建 Operator 角色,以便集群 Operator 可以发出 AWS API 调用。然后,这些角色被分配给之前创建的相应权限策略,以及带有 OIDC 供应商的信任策略。Operator 角色与集群范围的角色不同,它们最终代表需要访问 AWS 资源的 pod。因为用户无法将 IAM 角色附加到 pod,所以它们必须使用 OIDC 供应商创建信任策略,以便 Operator,因此 pod 可以访问它们所需的角色。

用户将角色分配给对应的策略权限后,最后一步是创建 OIDC 供应商。

云专家对创建流程进行解释

当需要新角色时,当前使用红帽角色的工作负载将假定 AWS 帐户中的角色,从 AWS STS 获取临时凭证,并开始使用所假定角色的权限策略允许的用户 AWS 帐户中的 API 调用执行操作。凭据是临时的,最长持续时间为一小时。

云专家对高级的信息解释

整个工作流在下图中描述:

云专家对整个流程解释

Operator 使用以下流程获取必要的凭证来执行其任务。每个 Operator 都会被分配一个 Operator 角色、权限策略和带有 OIDC 供应商的信任策略。Operator 将通过将包含角色和令牌文件的 JSON Web 令牌(web_identity_token_file)传递给 OIDC 供应商来假定角色,然后使用公钥验证签名密钥。公钥是在集群创建过程中创建的,并存储在 S3 存储桶中。然后,Operator 会确认签名令牌文件中的主题与角色信任策略中的角色匹配,以确保 OIDC 供应商只能获取允许的角色。然后,OIDC 供应商会向 Operator 返回临时凭证,以便 Operator 可以发出 AWS API 调用。有关视觉表示,请查看以下信息:

云专家传达了 oidc op roles

17.2.7. 使用 STS 的 ROSA 用例

在集群安装时创建节点

红帽安装程序使用 RH-Managed-OpenShift-Installer 角色和一个信任策略来假定客户帐户中 Managed-OpenShift-Installer-Role 角色。此过程从 AWS STS 返回临时凭证。安装程序开始使用从 STS 接收的临时凭证进行所需的 API 调用。安装程序在 AWS 中创建所需的基础架构。凭证在一小时内过期,安装程序无法再访问客户的帐户。

相同的流程也适用于支持问题单。在支持问题单中,红帽站点可靠性工程师(SRE)替换了安装程序。

扩展集群

machine-api-operator 使用 AssumeRoleWithWebIdentity 来假定 machine-api-aws-cloud-credentials 角色。这会启动集群 Operator 的顺序来接收凭证。machine-api-operator 角色现在可以发出相关的 API 调用来向集群添加更多 EC2 实例。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.