设计权限设置

本文档概述了在 Google Distributed Cloud (GDC) 网闸隔离配置环境中进行权限设计的最佳实践。具体涵盖以下主题：

虽然我们推荐以下设计，但您不一定要完全按照规定进行设计。每个 GDC Universe 都有独特的要求和注意事项，必须根据具体情况予以满足。

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

运营商必须为每个组织配置一个或多个身份提供方。然后，管理员连接到身份提供方，以管理 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 之外使用。
  • 请注意，对于有权创建和修改 Pod 的用户或服务账号，存在 Kubernetes 升级路径。
  • 将 expirationSeconds 字段设置为工作负载的服务账号令牌投影的短时间段。
  • 定期轮替服务账号凭证。

考虑最小权限原则

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

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

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

请务必检查组织内授予的角色，并审核是否存在权限过高的情况。您必须确保授予的角色是单个用户完成其工作所必需的，并且跨项目的角色组合不会导致权限提升或泄露风险。

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