设计权限设置

本文档概述了 Google Distributed Cloud (GDC) 气隙环境中的权限设计最佳实践。具体涵盖以下主题：

虽然我们建议采用以下设计，但您无需完全按照规定执行。每个 GDC 环境都有独特的要求和注意事项，必须根据具体情况满足这些要求和注意事项。

为每个组织配置一个身份提供方

运维人员必须为每个组织配置一个或多个身份提供方。然后， 管理员连接到身份提供方， 以管理 GDC 环境中应用的身份验证服务。

您可能会遇到这样一种情况：您的公司有多个部门，这些部门拥有单独的组织，并且每个组织都连接到同一个身份提供方进行身份验证。在这种情况下，您有责任了解和审核用户在各个组织中拥有的权限组合。确保在多个组织中拥有权限的用户不会违反将工作负载分离到不同组织的要求。

或者，您可能会遇到这样一种情况：不同的用户集使用不同的身份提供方在单个组织内进行身份验证，例如，当多个供应商团队在单个组织中协同工作时。考虑将用户身份整合到单个身份提供方中，还是维护单独的身份提供方，哪种方式最符合贵公司的身份管理方法。

为身份提供方配置多重身份验证

GDC 依赖于您的 IAM 平台进行身份验证，包括多重身份验证等其他安全设置。对于可能访问敏感资源的任何用户，最好使用实体密钥配置多重身份验证。

限制托管式服务和 Marketplace 服务

您可能希望阻止某些项目使用某些服务，以限制项目中的潜在攻击面或避免使用未经批准的服务。 默认情况下，人工智能和机器学习等托管式服务可在任何项目中使用。与托管式服务相比，必须先为组织启用 Marketplace 服务。

如需拒绝项目访问服务，请针对服务的 自定义资源定义和命名空间列表应用 Gatekeeper 限制条件。使用 Gatekeeper 拒绝访问的方法适用于托管式服务和 Marketplace 服务。

管理多个集群的 kubeconfig 文件

不同的运维任务需要连接到不同的集群。例如，您执行的任务包括将 IAM 角色绑定到项目，以及在 Kubernetes 集群上部署 Kubernetes Pod 资源。

使用 GDC 控制台时，您无需了解哪个底层集群执行任务，因为 GDC 控制台会抽象出连接到集群等低级别操作。

但是，在使用 gdcloud CLI 或 kubectl CLI 时，您可能需要使用多个 kubeconfig 文件来完成任务。确保您 使用 kubeconfig 凭据登录适用于任务的相应集群。

Kubernetes 服务账号的最佳实践

对于 Kubernetes 服务账号，授权基于 Secret 令牌。如需降低服务帐号令牌的风险，请考虑以下最佳实践：

  • 避免下载永久性服务帐号凭据以在 GDC 之外使用。
  • 了解 Kubernetes 升级路径 ，适用于有权创建和修改 pod 的用户或服务账号。
  • 将工作负载的服务账号令牌投影的 expirationSeconds 字段设置为较短的时间段。
  • 定期轮替服务帐号凭据。

考虑最小权限原则

向用户授予 角色绑定时，请考虑最小权限原则 (PoLP)。根据 PoLP，请考虑仅分配完成任务所需的权限。

例如，您在一个项目中向用户授予 Project IAM Admin 角色，以便该用户委派在该项目中授予角色的权限。 然后，该用户根据项目中的其他开发者使用的特定服务，向他们授予精细的角色。Project IAM Admin 角色必须仅限于受信任的主管，因为此角色可用于升级权限，以便在项目中为自己或他人授予其他角色。

定期审核是否存在过度权限

请务必审核组织内授予的角色，并审核是否存在过度权限。您必须确保授予的角色是个人用户完成工作所必需的，并且跨项目的角色组合不会导致权限升级或数据泄露风险。

如果贵公司使用多个组织，我们不建议单个用户在多个组织中拥有高权限角色，因为这可能会违反最初分离组织的原因。