GCP - Basic Information
资源层次结构
Google Cloud 使用 资源层次结构，在概念上类似于传统文件系统。这提供了一个逻辑的父/子工作流程，并为策略和权限提供了特定的附加点。
从高层次来看，它看起来像这样：
虚拟机（称为计算实例）是一种资源。资源位于项目中，可能与其他计算实例、存储桶等并存。
项目迁移
可以将没有任何组织的项目迁移到一个组织，需要的权限是roles/resourcemanager.projectCreator和roles/resourcemanager.projectMover。如果项目位于其他组织内，则需要联系GCP支持以先将其移出该组织。有关更多信息，请查看此处。
组织政策
允许集中控制您组织的云资源：
集中控制以配置限制，规定您组织的资源如何使用。
为您的开发团队定义和建立保护措施，以保持合规边界。
帮助项目所有者及其团队快速移动，而无需担心违反合规性。
这些政策可以创建以影响整个组织、文件夹或项目。目标资源层次节点的后代继承组织政策。
为了定义组织政策，您选择一个约束，这是针对Google Cloud服务或一组Google Cloud服务的特定类型的限制。您使用所需的限制配置该约束。
常见用例
根据域限制资源共享。
限制身份和访问管理服务帐户的使用。
限制新创建资源的物理位置。
禁用服务帐户创建。
还有许多其他约束可以让您对组织的资源进行细粒度控制。有关更多信息，请参见所有组织政策服务约束的列表。
默认组织政策
IAM角色
这些类似于AWS中的IAM政策，因为每个角色包含一组权限。
然而，与AWS不同的是，没有集中存储库的角色。相反，资源将X访问角色授予Y主体，而找出谁可以访问资源的唯一方法是使用**get-iam-policy方法**。
这可能是一个问题，因为这意味着找出主体拥有哪些权限的唯一方法是询问每个资源它授予了哪些权限，而用户可能没有权限从所有资源获取权限。
IAM中有三种类型的角色：
基本/原始角色，包括在引入IAM之前存在的所有者、编辑者和查看者角色。
预定义角色，为特定服务提供细粒度访问，并由Google Cloud管理。有很多预定义角色，您可以在此处查看它们及其权限这里。
自定义角色，根据用户指定的权限列表提供细粒度访问。
GCP中有成千上万的权限。要检查角色是否具有某个权限，您可以在此处搜索权限并查看哪些角色具有该权限。
您还可以在此处搜索预定义角色 由每个产品提供。 请注意，某些角色不能附加到用户，只能附加到SA，因为它们包含某些权限。 此外，请注意，权限只有在附加到相关服务时才会生效。
或者检查自定义角色是否可以使用特定权限。
用户
在GCP控制台中没有用户或组管理，这在Google Workspace中完成。尽管您可以在Google Workspace中同步不同的身份提供者。
您可以访问Workspaces的用户和组在https://admin.google.com。
MFA可以强制应用于Workspaces用户，然而，攻击者可以使用令牌通过CLI访问GCP，这不会受到MFA保护（仅在用户登录以生成时受到MFA保护：gcloud auth login）。
组
创建组织时，强烈建议创建几个组。如果您管理其中任何一个，您可能会危及整个组织或其重要部分：
默认密码政策
强制使用强密码
介于8到100个字符之间
不得重复使用
不得过期
如果人员通过第三方提供商访问Workspace，则不适用这些要求。
服务帐户
这些是资源可以附加并访问以便与GCP轻松交互的主体。例如，可以在元数据中访问附加到虚拟机的服务帐户的身份验证令牌。
在使用IAM和访问范围时，可能会遇到一些冲突。例如，您的服务帐户可能具有compute.instanceAdmin的IAM角色，但您入侵的实例已被限制为https://www.googleapis.com/auth/compute.readonly的范围限制。这将阻止您使用自动分配给实例的OAuth令牌进行任何更改。
这类似于AWS的IAM角色。但与AWS不同的是，任何服务帐户都可以附加到任何服务（不需要通过策略允许它）。
您将发现的几个服务帐户实际上是在您开始使用服务时由GCP自动生成的，例如：
然而，创建和附加到资源的 自定义服务账户 也是可能的，格式如下：
密钥与令牌
访问 GCP 作为服务账户主要有两种方式：
通过 OAuth 令牌：这些令牌可以从元数据端点或窃取的 http 请求中获取，并且受 访问范围 的限制。
密钥：这些是公钥和私钥对，允许您作为服务账户签署请求，甚至生成 OAuth 令牌以作为服务账户执行操作。这些密钥是危险的，因为它们更难以限制和控制，这就是 GCP 建议不要生成它们的原因。
请注意，每次创建服务账户时，GCP 会为服务账户生成一个密钥，用户无法访问（并且不会在 Web 应用程序中列出）。根据 这个帖子，这个密钥是 GCP 内部使用的，用于让元数据端点访问生成可访问的 OAuth 令牌。
访问范围
访问范围是 附加到生成的 OAuth 令牌 上以访问 GCP API 端点。它们 限制 OAuth 令牌的权限。 这意味着如果一个令牌属于资源的所有者，但在令牌范围内没有访问该资源的权限，则该令牌 无法被用来（滥用）这些权限。
谷歌实际上 建议 不使用访问范围，而完全依赖 IAM。Web 管理门户实际上强制执行这一点，但访问范围仍然可以通过编程方式应用于使用自定义服务账户的实例。
您可以通过 查询 来查看 分配的范围：
之前的 scopes 是使用 gcloud 默认生成的，用于访问数据。这是因为当你使用 gcloud 时，你首先创建一个 OAuth 令牌，然后用它来联系端点。
这些中最重要的 scope 可能是 cloud-platform，这基本上意味着可以 访问 GCP 中的任何服务。
你可以 在这里找到 所有可能的 scopes 列表.
如果你有 gcloud 浏览器凭据，可以 通过其他 scopes 获取令牌， 做一些类似于：
Terraform IAM 策略、绑定和成员
根据 terraform 在 https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam 中的定义，使用 terraform 与 GCP 有不同的方法来授予主体对资源的访问权限：
成员：您将 主体作为角色的成员 没有对角色或主体的限制。您可以将用户作为角色的成员，然后将组作为同一角色的成员，并且还可以将这些主体（用户和组）作为其他角色的成员。
绑定：多个 主体可以绑定到一个角色。这些 主体仍然可以绑定或成为其他角色的成员。但是，如果一个未绑定到角色的主体被设置为 绑定角色的成员，下次 绑定被应用时，成员资格将消失。
策略：策略是 权威的，它指示角色和主体，然后 这些主体不能有更多的角色，这些角色不能有更多的主体，除非该策略被修改（即使在其他策略、绑定或成员中也不行）。因此，当在策略中指定角色或主体时，其所有权限都被 该策略限制。显然，如果主体被赋予修改策略或权限提升权限的选项（例如创建新主体并将其绑定到新角色），则可以绕过此限制。
参考
Last updated
