关于
AWS 上的 OpenShift Service 文档.
摘要
第 1 章 Red Hat OpenShift Service on AWS 4 文档 复制链接链接已复制到粘贴板!
内容表
欢迎使用官方的 Red Hat OpenShift Service on AWS (ROSA)文档,您可以在其中了解 ROSA 并开始探索其功能。要了解 ROSA,使用 Red Hat OpenShift Cluster Manager 和命令行界面(CLI)工具(CLI)工具、使用体验以及与 Amazon Web Services (AWS)服务集成,从 ROSA 文档 开始。
要浏览 ROSA 文档,请使用左侧导航栏。
第 2 章 了解有关使用 HCP 的 ROSA 的更多信息 复制链接链接已复制到粘贴板!
带有托管 control plane (HCP)的 Red Hat OpenShift Service on AWS (ROSA)提供了减少的成本解决方案,以创建具有效率的受管 ROSA 集群。您可以快速创建新集群并在几分钟内部署应用程序。
2.1. 使用 HCP 的 ROSA 的主要功能 复制链接链接已复制到粘贴板!
- 使用 HCP 的 ROSA 至少需要两个节点,使其适合较小的项目,同时仍然能够扩展以支持较大的项目和企业。
- 底层 control plane 基础架构被完全管理。control plane 组件(如 API 服务器和 etcd 数据库)托管在红帽拥有的 AWS 帐户中。
- 调配时间约为 10 分钟。
- 客户可以单独升级 control plane 和机器池,这意味着他们不必在升级过程中关闭整个集群。
2.2. 使用 HCP 的 ROSA 入门 复制链接链接已复制到粘贴板!
使用以下部分查找内容以帮助您了解和使用带有 HCP 的 ROSA。
2.2.1. 架构 复制链接链接已复制到粘贴板!
了解使用 HCP 的 ROSA | 使用 HCP 部署计划 ROSA | 其他资源 |
---|---|---|
2.2.2. Cluster Administrator 复制链接链接已复制到粘贴板!
了解使用 HCP 的 ROSA | 使用 HCP 部署 ROSA | 使用 HCP 管理 ROSA | 其他资源 |
---|---|---|---|
2.2.3. 开发者 复制链接链接已复制到粘贴板!
了解使用 HCP 的 ROSA 中的应用程序开发 | 部署应用程序 | 其他资源 |
---|---|---|
Red Hat OpenShift Dev Spaces (以前称为 Red Hat CodeReady Workspaces) | ||
第 3 章 AWS STS 和 ROSA with HCP 解释 复制链接链接已复制到粘贴板!
带有托管 control plane (HCP)的 Red Hat OpenShift Service on AWS (ROSA)将 AWS (Amazon Web Services)安全令牌服务(STS)用于 AWS Identity Access Management (IAM)来获取所需的凭证,以便与 AWS 帐户中的资源交互。
3.1. AWS STS 凭证方法 复制链接链接已复制到粘贴板!
作为使用 HCP 的 ROSA 的一部分,红帽必须获得管理 AWS 帐户中的基础架构资源所需的权限。使用 HCP 的 ROSA 授予集群的自动化软件有限,对 AWS 帐户中资源的短期访问权限。
STS 方法使用预定义的角色和策略为 IAM 角色授予临时、最低特权权限。凭证通常在请求后的一小时后过期。到期后,AWS 不再识别它们,不再有来自使用它们的 API 请求的帐户访问权限。如需更多信息,请参阅 AWS 文档。
必须为每个使用 HCP 集群的 ROSA 创建 AWS IAM STS 角色。ROSA 命令行界面(CLI) (rosa
)管理 STS 角色,并帮助您将特定于 ROSA 的 AWS 管理策略附加到每个角色。CLI 提供了用于创建角色、附加 AWS 管理的策略的命令和文件,以及允许 CLI 自动创建角色和附加策略的选项。
3.2. AWS STS 安全 复制链接链接已复制到粘贴板!
AWS STS 的安全功能包括:
用户提前创建的明确和有限的策略集合。
- 用户可以检查平台所需的每个请求权限。
- 该服务不能在这些权限外进行任何操作。
- 不需要轮转或撤销凭证。每当服务需要执行操作时,它会获得在一小时或更短时间内过期的凭证。
- 凭证过期会降低凭证泄漏和重复使用的风险。
使用 HCP 的 ROSA 将集群软件组件授予具有短期安全凭证到特定和隔离的 IAM 角色的最低权限。凭证与特定于每个组件的 IAM 角色和发出 AWS API 调用的集群关联。此方法与云服务资源管理中最低特权和安全实践的原则一致。
3.3. 使用 HCP 的 ROSA 组件 复制链接链接已复制到粘贴板!
- AWS 基础架构 - 集群所需的基础架构,包括 Amazon EC2 实例、Amazon EBS 存储和网络组件。如需有关云资源配置的更多信息,请参阅 AWS 计算类型,以查看计算节点的支持的实例类型 和 置备的 AWS 基础架构。
- AWS STS - 授权短期动态令牌的方法,为用户提供了临时与 AWS 帐户资源交互所需的权限。
- OpenID Connect (OIDC) - 集群 Operator 使用 AWS 进行身份验证的机制,假设集群角色通过信任策略从 AWS IAM STS 获取临时凭证,以便从 AWS IAM STS 进行所需的 API 调用。
角色和策略 - ROSA 与 HCP 使用的角色和策略可以划分为集群范围的角色和策略,以及 Operator 角色和策略。
策略决定了每个角色允许的操作。有关各个角色和策略的详情,请参阅关于 IAM 资源。有关信任策略的详情,请参阅 ROSA IAM 角色资源。
集群范围的角色有:
-
<prefix>-HCP-ROSA-Worker-Role
-
<prefix>-HCP-ROSA-Support-Role
-
<prefix>-HCP-ROSA-Installer-Role
-
帐户范围的 AWS 管理策略有:
- ROSAInstallerPolicy
- ROSAWorkerInstancePolicy
- ROSASRESupportPolicy
- ROSAIngressOperatorPolicy
- ROSAAmazonEBSCSIDriverOperatorPolicy
- ROSACloudNetworkConfigOperatorPolicy
- ROSAControlPlaneOperatorPolicy
- ROSAImageRegistryOperatorPolicy
- ROSAKMSProviderPolicy
- ROSAKubeControllerPolicy
- ROSAManageSubscription
- ROSANodePoolManagementPolicy
注意集群 Operator 角色使用某些策略,如下所列。Operator 角色在第二步骤中创建,因为它们依赖于现有集群名称,且不能与集群范围的角色同时创建。
Operator 角色有:
- <operator_role_prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials
- <operator_role_prefix>-openshift-cloud-network-config-controller-cloud-credentials
- <operator_role_prefix>-openshift-machine-api-aws-cloud-credentials
- <operator_role_prefix>-openshift-cloud-credential-operator-cloud-credentials
- <operator_role_prefix>-openshift-image-registry-installer-cloud-credentials
- <operator_role_prefix>-openshift-ingress-operator-cloud-credentials
- 为每个帐户范围的角色和每个 Operator 角色和每个 Operator 角色创建信任策略。
3.4. 使用 HCP 集群部署 ROSA 复制链接链接已复制到粘贴板!
按照以下步骤部署带有 HCP 集群的 ROSA:
- 您可以创建集群范围的角色。
- 您可以创建 Operator 角色。
- 红帽使用 AWS STS 将所需的权限发送到 AWS,以允许 AWS 创建并附加对应的 AWS 管理的 Operator 策略。
- 您可以创建 OIDC 供应商。
- 创建集群。
在集群创建过程中,ROSA CLI 会为您创建所需的 JSON 文件,并输出您需要的命令。如果需要,ROSA CLI 也可以为您运行命令。
ROSA CLI 可以自动为您创建角色,也可以使用- mode manual 或-
标志手动创建它们。有关部署的详情,请参阅使用自定义创建集群。
mode
auto
3.5. 使用 HCP 工作流的 ROSA 复制链接链接已复制到粘贴板!
用户创建所需的集群范围的角色。在创建角色期间,会创建信任策略(称为跨帐户信任策略),允许红帽拥有的角色假定角色。另外,还会为 EC2 服务创建信任策略,该服务允许 EC2 实例上的工作负载假定角色和获取凭证。AWS 为每个角色分配对应的权限策略。
创建集群范围的角色和策略后,用户可以创建集群。启动集群创建后,用户会创建 Operator 角色,以便集群 Operator 能够发出 AWS API 调用。然后,这些角色被分配给之前创建的相应权限策略,并使用 OIDC 供应商创建信任策略。Operator 角色与 中的集群范围的角色不同,它们最终代表需要访问 AWS 资源的 pod。因为用户无法将 IAM 角色附加到 pod,所以它们必须使用 OIDC 供应商创建信任策略,以便 Operator 可以访问其所需的角色。
用户将角色分配给对应的策略权限后,最后一步会创建 OIDC 供应商。
当需要新角色时,当前使用红帽角色的工作负载将假定 AWS 帐户中的角色,从 AWS STS 获取临时凭证,并开始使用假定的角色 AWS 帐户中的 API 调用来执行操作。凭证是临时的,最长持续时间为一小时。
Operator 使用以下流程来获取必要的凭证来执行其任务。每个 Operator 都会被分配一个 Operator 角色、权限策略和带有 OIDC 供应商的信任策略。Operator 将通过将包含角色和令牌文件(web_identity_token_file
)的 JSON Web 令牌传递给 OIDC 供应商来假设角色,然后使用公钥验证签名密钥。公钥在集群创建过程中创建,并存储在 S3 存储桶中。然后,Operator 会确认签名的令牌文件中的主题与角色信任策略中的角色匹配,以确保 OIDC 供应商只能获取允许的角色。然后,OIDC 供应商会将临时凭证返回到 Operator,以便 Operator 能够发出 AWS API 调用。有关视觉表示,请查看以下图:
Legal Notice
复制链接链接已复制到粘贴板!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.