2.4. SRE 和服务帐户访问
2.4.1. 身份和访问管理
红帽站点可靠性工程 (SRE) 团队的大部分访问是通过自动化配置管理的集群 Operator 来完成。
使用 Workload Identify Federation (WIF)身份验证类型创建的 Google Cloud Platform (GCP)集群上的 OpenShift Dedicated 不使用 Operator 进行 SRE 访问。相反，SRE 帐户访问所需的角色会被分配给 sd-sre-platform-gcp-access 组，作为 WIF 配置创建的一部分，并在 OpenShift Cluster Manager 部署集群前进行验证。有关 WIF 配置的更多信息，请参阅 其他资源。
2.4.1.1. 子处理器
有关可用子处理器列表，请查看红帽客户门户网站上的红帽子处理器列表。
2.4.1.2. SRE 访问所有 OpenShift Dedicated 集群
SREs 通过代理访问 OpenShift Dedicated 集群。代理会在 OpenShift Dedicated 集群中登录时为 SREs 使用服务帐户进行 mint。因为没有为 OpenShift Dedicated 集群配置身份提供程序，因此 SREs 通过运行本地 Web 控制台容器来访问代理。SRE 无法直接访问集群 Web 控制台。SRE 必须以单独的用户身份进行身份验证以确保可审核性。所有验证尝试都会记录到安全信息和事件管理 (SIEM) 系统。
2.4.1.3. OpenShift Dedicated 中的特权访问控制
Red Hat SRE 在访问 OpenShift Dedicated 和公有云供应商组件时遵循最小特权原则。SRE 访问有四个基本类别：
- SRE 管理员通过带有正常双因素身份验证的红帽客户门户网站访问，且没有特权提升。
- SRE 管理通过带有正常双因素身份验证的 Red Hat Enterprise SSO 访问，且没有特权升级。
- OpenShift elevation，这是使用红帽 SSO 的手动提升。它经过全面审核，每个操作 SREs 都需要管理批准。
- 云供应商访问或提升，这是云供应商控制台或 CLI 访问的手动提升。访问仅限于 60 分钟，并且完全审核。
每种访问类型对组件有不同的访问权限级别：
| 组件 | 典型的 SRE 管理访问权限（红帽客户门户） | 典型的 SRE 管理员访问权限（红帽 SSO） | OpenShift elevation | 云供应商访问 |
|---|---|---|---|---|
| OpenShift Cluster Manager | R/W | 无权限 | 无权限 | 无权限 |
| OpenShift web 控制台 | 无权限 | R/W | R/W | 无权限 |
| 节点操作系统 | 无权限 | 提升 OS 和网络权限的特定列表。 | 提升 OS 和网络权限的特定列表。 | 无权限 |
| AWS 控制台 | 无权限 | 没有访问权限，但这是用于请求云供应商访问的帐户。 | 无权限 | 使用 SRE 身份的所有云供应商权限。 |
2.4.1.4. SRE 对云基础架构帐户的访问
红帽人员在日常 OpenShift Dedicated 操作中无法访问云基础架构帐户。出于紧急故障排除目的，Red Hat SRE 具有定义并可审核的流程来访问云基础架构帐户。
在 AWS 中，SRE 使用 AWS 安全令牌服务(STS)为 BYOCAdminAccess 用户生成简短的 AWS 访问令牌。对 STS 令牌的访问会被记录，可追溯到单个用户。BYOCAdminAccess 附加了 AdministratorAccess IAM 策略。
在 Google Cloud 中，SRES 在针对 Red Hat SAML 身份提供程序(IDP)进行身份验证后访问资源。IDP 授权有生存时间过期的令牌。令牌的颁发由企业红帽 IT 进行审核，并链接到个人用户。
2.4.1.5. 红帽支持访问
红帽 CEE 团队的成员通常对集群的部分具有只读访问权限。具体来说，CEE 对核心和产品命名空间具有有限访问权限，且无法访问客户命名空间。
| 角色 | Core 命名空间 | 层次产品命名空间 | Customer 命名空间 | 云基础架构帐户* |
|---|---|---|---|---|
| OpenShift SRE | Read: All Write: Very Limited [1] | Read: All Write: None | Read: None[2] Write: None | Read: All [3] Write: All [3] |
| CEE | Read: All Write: None | Read: All Write: None | Read: None[2] Write: None | Read: None Write: None |
| 客户管理员 | Read: None Write: None | Read: None Write: None | Read: All Write: All | Read: Limited[4] Write: Limited[4] |
| 客户用户 | Read: None Write: None | Read: None Write: None | Read: Limited[5] Write: Limited[5] | Read: None Write: None |
| 其他人 | Read: None Write: None | Read: None Write: None | Read: None Write: None | Read: None Write: None |
Cloud Infrastructure Account 指的是底层 AWS 或 Google Cloud 帐户
- 仅限于解决常见用例，如部署失败、升级集群并替换错误的 worker 节点。
- 默认情况下，红帽人员无法访问客户数据。
- SRE 对云基础架构帐户的访问是一个"break-glass"过程，用于在记录的事件期间进行故障排除。
- 客户管理员通过 Cloud Infrastructure Access 限制对云基础架构帐户控制台的访问权限。
- 限制为通过 RBAC 授予的内容，以及用户创建的命名空间。
2.4.1.6. 客户访问权限
客户访问权限仅限于由客户管理员角色使用 RBAC 授予权限创建的命名空间。通常不允许访问底层基础架构或产品命名空间，而无需 cluster-admin 访问。有关客户访问和身份验证的更多信息，请参阅文档中的"观察身份验证"部分。
2.4.1.7. 访问批准及审核
新的 SRE 用户访问需要管理批准。通过自动过程将经过隔离或传输的 SRE 帐户作为授权用户删除。另外，SRE 会执行定期访问审核，包括授权用户列表的管理登录。
2.4.2. SRE 集群访问
SRE 对 OpenShift Dedicated 集群的访问是通过多个所需身份验证层控制的，它们都由严格的公司策略管理。所有身份验证尝试访问集群以及集群中所做的更改都会记录在审计日志中，以及负责这些操作的 SRE 的特定帐户身份。这些审计日志有助于确保 SREs 对客户集群进行的所有更改遵循组成红帽受管服务指南的严格的策略和步骤。
以下是 SRE 必须执行的进程的概述，以访问客户的集群。
- SRE 从 Red Hat SSO （云服务）请求刷新的 ID 令牌。此请求经过身份验证。令牌在十五分钟内有效。令牌过期后，您可以再次刷新令牌并接收新令牌。刷新到一个新令牌的能力是无限的，但刷新到一个新令牌的能力会在 30 不活跃后被撤销。
- SRE 连接到红帽 VPN。VPN 身份验证由 Red Hat Corporate Identity and Access Management system (RH IAM)完成。使用 RH IAM 时，SRE 是多因素的，可以根据组和现有载入和关闭进程在内部管理。当 SRE 进行身份验证并连接后，SRE 可以访问云服务团队管理平面。对云服务团队管理平面的更改需要许多层的批准，并由严格的公司策略维护。
- 授权完成后，SRE 会登录到 fleet management plane，并接收由 fleet management plane 创建的服务帐户令牌。令牌有效 15 分钟。当令牌不再有效后，它会被删除。
在授予 fleet management plane 的访问权限后，SRE 会使用各种方法访问集群，具体取决于网络配置。
- 访问私有或公共集群 ： 请求通过特定的 Network Load Balancer (NLB)发送，方法是使用端口 6443 上的加密 HTTP 连接。
- 访问 PrivateLink 集群 ： 请求发送到红帽 Transit 网关，然后连接到每个区域的 Red Hat VPC。接收请求的 VPC 将依赖于目标私有集群的区域。在 VPC 中，有一个专用子网，其中包含到客户的 PrivateLink 集群 的 PrivateLink 端点。
2.4.3. 服务帐户如何假定 SRE 拥有的项目中的 AWS IAM 角色
安装使用 AWS 安全令牌服务 (STS) 的 OpenShift Dedicated 集群时，会创建特定于集群的 Operator AWS Identity and Access Management (IAM) 角色。这些 IAM 角色允许 OpenShift Dedicated 集群 Operator 运行核心 OpenShift 功能。
集群 Operator 使用服务帐户假设 IAM 角色。当服务帐户假设 IAM 角色时，会为集群 Operator 的 pod 中使用的服务帐户提供临时 STS 凭证。如果假设角色具有所需的 AWS 权限，则服务帐户可以在 pod 中运行 AWS SDK 操作。
在 SRE 拥有的项目中假设 AWS IAM 角色的工作流
下图演示了在 SRE 拥有的项目中假设 AWS IAM 角色的工作流：
图 2.1. 在 SRE 拥有的项目中假设 AWS IAM 角色的工作流
工作流有以下阶段：
在集群 Operator 运行的每个项目中，Operator 的部署 spec 具有投射服务帐户令牌的卷挂载，以及包含 pod 的 AWS 凭证配置的 secret。令牌是面向使用者和限时的。每小时，OpenShift Dedicated 会生成新令牌，AWS SDK 会读取包含 AWS 凭证配置的挂载的 secret。此配置具有到挂载令牌的路径和 AWS IAM 角色 ARN。secret 的凭证配置包括：
-
一个
$AWS_ARN_ROLE变量，其中包含具有运行 AWS SDK 操作所需的权限的 IAM 角色的 ARN。 -
$AWS_WEB_IDENTITY_TOKEN_FILE变量，在 pod 中具有到服务帐户的 OpenID Connect (OIDC)令牌的完整路径。完整路径为/var/run/secrets/openshift/serviceaccount/token。
-
一个
-
当集群 Operator 需要假设 AWS IAM 角色访问 AWS 服务（如 EC2）时，Operator 上运行的 AWS SDK 客户端代码会调用
AssumeRoleWithWebIdentityAPI 调用。 OIDC 令牌从 pod 传递给 OIDC 供应商。如果满足以下要求，供应商会验证服务帐户身份：
- 身份签名由私钥有效并签名。
sts.amazonaws.com使用者列在 OIDC 令牌中，并与 OIDC 供应商中配置的 audience 匹配。注意在带有 STS 集群的 OpenShift Dedicated 中，OIDC 供应商会在安装过程中创建，并默认设置为服务帐户签发者。
sts.amazonaws.com使用者默认在 OIDC 供应商中设置。- OIDC 令牌没有过期。
- 令牌中的签发者值具有 OIDC 供应商的 URL。
- 如果项目和服务帐户位于被假定的 IAM 角色的信任策略范围内，则授权会成功。
- 成功身份验证和授权后，临时 AWS STS 凭证以 AWS 访问令牌、secret 密钥和会话令牌的形式传递给 pod，供服务帐户使用。通过使用凭证，服务帐户会临时授予 IAM 角色中启用的 AWS 权限。
- 当集群 Operator 运行时，使用 pod 中的 AWS SDK 的 Operator 会消耗具有投射服务帐户和 AWS IAM 角色 ARN 的 secret，以针对 OIDC 供应商进行身份验证。OIDC 供应商返回临时 STS 凭证，用于针对 AWS API 进行身份验证。
2.4.4. 其他资源
有关 WIF 配置和 SRE 访问角色的更多信息，请参阅创建 WIF 配置。
