此页面由 Cloud Translation API 翻译。

设计权限设置

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

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

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

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

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

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

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

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

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

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

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

不过，在使用 gdcloud CLI 或 kubectl CLI 时，您可能需要使用多个 kubeconfig 文件来完成任务。确保您使用 kubeconfig 凭据登录到适合您任务的集群。

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

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

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

请务必查看组织内授予的角色，并审核是否存在权限过大的情况。您必须确保授予的角色是单个用户完成其工作所必需的，并且项目中的角色组合不会导致权限升级或数据渗漏风险。

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