GCP - Basic Information
资源层次结构
Google Cloud 使用一个 资源层次结构,概念上类似于传统的文件系统。这提供了一个逻辑上的父/子工作流,并为策略和权限提供了特定的附加点。
在高层次上,它看起来像这样:
一台虚拟机(称为 Compute Instance)是一个资源。一个资源驻留在一个项目中,可能与其他 Compute Instances、存储桶等一起存在。
项目迁移
在没有任何组织的情况下,可以通过具有 roles/resourcemanager.projectCreator
和 roles/resourcemanager.projectMover
权限的组织来迁移项目。如果项目在其他组织内,则需要联系 GCP 支持首先将其移出组织。更多信息请查看此处。
组织政策
允许集中控制组织的云资源:
集中控制以配置限制,规定组织资源的使用方式。
为开发团队定义和建立护栏,确保其在合规范围内活动。
帮助项目所有者及其团队快速行动,而无需担心违反合规。
这些政策可以创建以影响整个组织、文件夹或项目。目标资源层次结构节点的后代继承组织政策。
为了定义组织政策,你选择一个约束,这是对 Google Cloud 服务或一组 Google Cloud 服务的特定类型的限制。你根据所需的限制配置该约束。
常见用例
基于域限制资源共享。
限制 Identity and Access Management 服务账户的使用。
限制新创建资源的物理位置。
禁用服务账户创建。
还有许多其他约束可以对组织的资源进行细粒度控制。有关更多信息,请参见所有组织政策服务约束的列表。
默认组织政策
IAM 角色
这些类似于 AWS 中的 IAM 政策,因为每个角色包含一组权限。
然而,与 AWS 不同的是,没有集中存储库来存储角色。相反,资源为 Y 主体提供 X 访问角色,唯一的方法是使用**get-iam-policy
方法获取该资源的权限**。
这可能是一个问题,因为这意味着唯一的方法是询问每个资源它授予了哪些权限,而用户可能没有权限从所有资源获取权限。
IAM 中有三种类型的角色:
基本/原始角色,包括在引入 IAM 之前存在的所有者、编辑者和查看者角色。
预定义角色,为特定服务提供细粒度访问权限,由 Google Cloud 管理。有很多预定义角色,你可以在此处查看所有角色及其权限这里。
自定义角色,根据用户指定的权限列表提供细粒度访问权限。
GCP 中有成千上万的权限。为了检查某个角色是否具有某个权限,你可以在此处搜索权限并查看哪些角色具有该权限。
你还可以在此处搜索预定义角色,由每个产品提供。请注意,某些角色不能附加到用户,只能附加到 SAs,因为它们包含某些权限。 此外,请注意,权限只有在附加到相关服务时才会生效。
或者检查自定义角色是否可以使用特定权限在这里。
GCP - IAM, Principals & Org Policies Enum用户
在GCP 控制台中没有用户或组管理,这是在Google Workspace中完成的。尽管你可以在 Google Workspace 中同步不同的身份提供者。
你可以访问 Workspaces 用户和组在https://admin.google.com。
MFA 可以强制 Workspaces 用户使用,但攻击者可以使用令牌通过 cli 访问 GCP**,这不会受到 MFA 保护**(只有当用户登录生成它时才会受到 MFA 保护:gcloud auth login
)。
组
当创建一个组织时,强烈建议创建几个组。如果你管理其中任何一个,你可能已经妥协了整个或重要部分的组织:
组 | 功能 |
| 管理属于组织的任何资源。谨慎分配此角色;组织管理员可以访问所有 Google Cloud 资源。或者,由于此功能权限很高,考虑使用个人账户而不是创建组。 |
| 创建网络、子网、防火墙规则和网络设备,如 Cloud Router、Cloud VPN 和云负载均衡器。 |
| 设置计费账户并监控其使用情况。 |
| 设计、编码和测试应用程序。 |
| 为整个组织建立和管理安全政策,包括访问管理和组织约束政策。有关规划 Google Cloud 安全基础设施的更多信息,请参见Google Cloud 安全基础指南。 |
| 创建或管理支持持续集成和交付、监控和系统配置的端到端管道。 |
| |
| |
| |
| 监控项目的支出。典型成员是财务团队的一部分。 |
| 审查整个 Google Cloud 组织的资源信息。 |
| 审查云安全。 |
| 审查网络配置。 |
| 查看审计日志。 |
| 管理 Security Command Center。 |
| 管理 Secret Manager 中的秘密。 |
默认密码政策
强制使用强密码
长度在 8 到 100 个字符之间
不允许重复使用
无到期
如果通过第三方提供商访问 Workspace,这些要求不适用。
服务账户
这些是资源可以附加并访问以便与 GCP 轻松交互的主体。例如,可以在元数据中访问附加到虚拟机的服务账户的身份验证令牌。
使用 IAM 和访问范围时可能会遇到一些冲突。例如,你的服务账户可能具有 compute.instanceAdmin
的 IAM 角色,但你入侵的实例被限制为 https://www.googleapis.com/auth/compute.readonly
的范围。这将阻止你使用自动分配给实例的 OAuth 令牌进行任何更改。
这类似于 AWS 的IAM 角色。但与 AWS 不同,任何服务账户都可以附加到任何服务(不需要通过策略允许)。
你会发现的几个服务账户实际上是当你开始使用某个服务时由 GCP 自动生成的,例如:
然而,也可以创建和附加到资源自定义服务帐户,其外观如下:
Access scopes
访问范围是附加到生成的OAuth令牌以访问GCP API端点的。它们限制了OAuth令牌的权限。 这意味着如果一个令牌属于资源的所有者,但在令牌范围内没有访问该资源的权限,则该令牌不能用于(滥用)这些特权。
谷歌实际上建议 不要使用访问范围,而是完全依赖IAM。网络管理门户实际上强制执行这一点,但访问范围仍然可以通过编程方式应用于使用自定义服务帐户的实例。
你可以通过查询来查看分配的 范围:
前面的 scopes 是使用 gcloud
访问数据时 默认 生成的。这是因为当你使用 gcloud
时,首先会创建一个 OAuth 令牌,然后使用它来联系端点。
其中最重要的 scope 可能是 cloud-platform
,这基本上意味着可以 访问 GCP 中的任何服务。
你可以 在这里找到所有可能的 scopes 列表 all the possible scopes in here.
如果你有 gcloud
浏览器凭证,可以通过以下方式 获取具有其他 scopes 的令牌:
Terraform IAM Policies, Bindings and Memberships
根据terraform在https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam中的定义,使用terraform与GCP时,有不同的方法授予主体对资源的访问权限:
Memberships: 你可以将主体设置为角色的成员,没有对角色或主体的限制。你可以将一个用户设置为一个角色的成员,然后将一个组设置为同一角色的成员,并且还可以将这些主体(用户和组)设置为其他角色的成员。
Bindings: 多个主体可以绑定到一个角色。这些主体仍然可以绑定或成为其他角色的成员。然而,如果一个未绑定到该角色的主体被设置为绑定角色的成员,那么下次应用绑定时,该成员资格将消失。
Policies: 策略是权威性的,它指示角色和主体,然后,这些主体不能有更多的角色,这些角色不能有更多的主体,除非该策略被修改(即使在其他策略、绑定或成员资格中也不行)。因此,当策略中指定了一个角色或主体时,其所有权限都受该策略限制。显然,如果主体被赋予修改策略或权限提升的权限(如创建一个新主体并将其绑定到一个新角色),这可以被绕过。
References
Last updated