Chinese - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - Basic Information

支持 HackTricks

资源层次结构

Google Cloud 使用一个 资源层次结构，概念上类似于传统的文件系统。这提供了一个逻辑上的父/子工作流，并为策略和权限提供了特定的附加点。

在高层次上，它看起来像这样：

Organization
--> Folders
--> Projects
--> Resources

一台虚拟机（称为 Compute Instance）是一个资源。一个资源驻留在一个项目中，可能与其他 Compute Instances、存储桶等一起存在。

项目迁移

在没有任何组织的情况下，可以通过具有 roles/resourcemanager.projectCreator 和 roles/resourcemanager.projectMover 权限的组织来迁移项目。如果项目在其他组织内，则需要联系 GCP 支持首先将其移出组织。更多信息请查看此处。

组织政策

允许集中控制组织的云资源：

  • 集中控制以配置限制，规定组织资源的使用方式。

  • 为开发团队定义和建立护栏，确保其在合规范围内活动。

  • 帮助项目所有者及其团队快速行动，而无需担心违反合规。

这些政策可以创建以影响整个组织、文件夹或项目。目标资源层次结构节点的后代继承组织政策。

为了定义组织政策，你选择一个约束，这是对 Google Cloud 服务或一组 Google Cloud 服务的特定类型的限制。你根据所需的限制配置该约束。

常见用例

  • 基于域限制资源共享。

  • 限制 Identity and Access Management 服务账户的使用。

  • 限制新创建资源的物理位置。

  • 禁用服务账户创建。

还有许多其他约束可以对组织的资源进行细粒度控制。有关更多信息，请参见所有组织政策服务约束的列表。

默认组织政策

这些是 Google 在设置 GCP 组织时默认添加的政策：

访问管理政策

  • 域限制联系人： 防止将用户添加到指定域之外的 Essential Contacts。这限制了 Essential Contacts 仅允许选定域中的托管用户身份接收平台通知。

  • 域限制共享： 防止将用户添加到指定域之外的 IAM 政策。这限制了 IAM 政策仅允许选定域中的托管用户身份访问组织内的资源。

  • 公共访问预防： 防止 Cloud Storage 存储桶暴露给公众。这确保开发人员无法配置 Cloud Storage 存储桶以进行未经身份验证的互联网访问。

  • 统一存储桶级别访问： 防止 Cloud Storage 存储桶中的对象级访问控制列表（ACL）。这通过在所有 Cloud Storage 存储桶对象上一致地应用 IAM 政策来简化访问管理。

  • 要求 OS 登录： 在新项目中创建的虚拟机将启用 OS 登录。这使你可以使用 IAM 管理对实例的 SSH 访问，而无需创建和管理单个 SSH 密钥。

服务账户的附加安全政策

  • 禁用自动 IAM 授权： 防止默认的 App Engine 和 Compute Engine 服务账户在项目创建时自动获得 Editor IAM 角色。这确保服务账户在创建时不会获得过度权限的 IAM 角色。

  • 禁用服务账户密钥创建： 防止创建公共服务账户密钥。这有助于减少暴露持久凭证的风险。

  • 禁用服务账户密钥上传： 防止上传公共服务账户密钥。这有助于减少泄露或重复使用密钥材料的风险。

安全 VPC 网络配置政策

  • 定义 VM 实例的允许外部 IP： 防止创建具有公共 IP 的 Compute 实例，这可能会将其暴露给互联网流量。

  • 禁用 VM 嵌套虚拟化： 防止在 Compute Engine 虚拟机上创建嵌套虚拟机。这减少了未监控嵌套虚拟机的安全风险。

  • 禁用 VM 串行端口： 防止对 Compute Engine 虚拟机的串行端口访问。这防止使用 Compute Engine API 向服务器的串行端口输入。

  • 限制 Cloud SQL 实例上的授权网络： 防止公共或非内部网络范围访问 Cloud SQL 数据库。

  • 基于 IP 地址类型限制协议转发： 防止 VM 协议转发外部 IP 地址。

  • 限制 Cloud SQL 实例的公共 IP 访问： 防止创建具有公共 IP 的 Cloud SQL 实例，这可能会将其暴露给互联网流量。

  • 限制共享 VPC 项目留置权移除： 防止意外删除共享 VPC 主机项目。

  • 将新项目的内部 DNS 设置为仅区域 DNS： 防止使用服务可用性较低的旧版 DNS 设置。

  • 跳过默认网络创建： 防止自动创建默认 VPC 网络及相关资源。这避免了过度权限的默认防火墙规则。

  • 禁用 VPC 外部 IPv6 使用： 防止创建外部 IPv6 子网，这可能会暴露给未经授权的互联网访问。

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）。

组

当创建一个组织时，强烈建议创建几个组。如果你管理其中任何一个，你可能已经妥协了整个或重要部分的组织：

组

功能

gcp-organization-admins （检查表所需的组或个人账户）

管理属于组织的任何资源。谨慎分配此角色；组织管理员可以访问所有 Google Cloud 资源。或者，由于此功能权限很高，考虑使用个人账户而不是创建组。

gcp-network-admins （检查表所需）

创建网络、子网、防火墙规则和网络设备，如 Cloud Router、Cloud VPN 和云负载均衡器。

gcp-billing-admins （检查表所需）

设置计费账户并监控其使用情况。

gcp-developers （检查表所需）

设计、编码和测试应用程序。

gcp-security-admins

为整个组织建立和管理安全政策，包括访问管理和组织约束政策。有关规划 Google Cloud 安全基础设施的更多信息，请参见Google Cloud 安全基础指南。

gcp-devops

创建或管理支持持续集成和交付、监控和系统配置的端到端管道。

gcp-logging-admins

gcp-logging-viewers

gcp-monitor-admins

gcp-billing-viewer （不再默认）

监控项目的支出。典型成员是财务团队的一部分。

gcp-platform-viewer （不再默认）

审查整个 Google Cloud 组织的资源信息。

gcp-security-reviewer （不再默认）

审查云安全。

gcp-network-viewer （不再默认）

审查网络配置。

grp-gcp-audit-viewer （不再默认）

查看审计日志。

gcp-scc-admin （不再默认）

管理 Security Command Center。

gcp-secrets-admin （不再默认）

管理 Secret Manager 中的秘密。

默认密码政策

  • 强制使用强密码

  • 长度在 8 到 100 个字符之间

  • 不允许重复使用

  • 无到期

  • 如果通过第三方提供商访问 Workspace，这些要求不适用。

服务账户

这些是资源可以附加并访问以便与 GCP 轻松交互的主体。例如，可以在元数据中访问附加到虚拟机的服务账户的身份验证令牌。 使用 IAM 和访问范围时可能会遇到一些冲突。例如，你的服务账户可能具有 compute.instanceAdmin 的 IAM 角色，但你入侵的实例被限制为 https://www.googleapis.com/auth/compute.readonly 的范围。这将阻止你使用自动分配给实例的 OAuth 令牌进行任何更改。

这类似于 AWS 的IAM 角色。但与 AWS 不同，任何服务账户都可以附加到任何服务（不需要通过策略允许）。

你会发现的几个服务账户实际上是当你开始使用某个服务时由 GCP 自动生成的，例如：

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

然而，也可以创建和附加到资源自定义服务帐户，其外观如下：

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Access scopes

访问范围是附加到生成的OAuth令牌以访问GCP API端点的。它们限制了OAuth令牌的权限。 这意味着如果一个令牌属于资源的所有者，但在令牌范围内没有访问该资源的权限，则该令牌不能用于（滥用）这些特权。

谷歌实际上建议 不要使用访问范围，而是完全依赖IAM。网络管理门户实际上强制执行这一点，但访问范围仍然可以通过编程方式应用于使用自定义服务帐户的实例。

你可以通过查询来查看分配的 范围：

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

前面的 scopes 是使用 gcloud 访问数据时 默认 生成的。这是因为当你使用 gcloud 时，首先会创建一个 OAuth 令牌，然后使用它来联系端点。

其中最重要的 scope 可能是 cloud-platform，这基本上意味着可以 访问 GCP 中的任何服务。

你可以 在这里找到所有可能的 scopes 列表 all the possible scopes in here.

如果你有 gcloud 浏览器凭证，可以通过以下方式 获取具有其他 scopes 的令牌：

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

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

支持HackTricks
PreviousGCP PentestingNextGCP - Federation Abuse

Last updated