Google ACE: 资源层次结构、IAM 和计费管理 — 学习指南
属于 Google Associate Cloud Engineer — 学习指南. 使用经过验证的答案练习: Google 考试中心, 或参加限时模拟考试: ExamRoll.io.
概览
资源层次结构、身份和访问管理 (IAM) 以及结算管理构成了 Google Cloud 运营的控制平面。一个具有弹性的设计始于清晰的层次结构(组织、文件夹、项目),以界定策略范围和明确责任;应用最小权限原则的 IAM,采用以群组为中心的管理方式,并为工作负载使用短期凭证;利用预算、导出和标签进行成本归因;并通过组织策略和全面的审计日志来强制执行治理。卓越运营源于标准化继承、集中化结算和日志,以及使用服务账号模拟而非长期有效的密钥。本节详细介绍核心构造、其预期用途以及需要避免的常见故障模式。
资源层次结构和身份模型
资源层次结构
- Organization:根节点,通过 Cloud Identity 或 Google Workspace 创建。拥有全局策略(IAM、组织策略、标签)。
- Folders:可选的分组方式,用于部门、环境(例如,dev、prod)或应用程序。有助于委托管理和策略范围界定。
- Projects:用于资源、API、配额、IAM 和结算关联的管理边界。大多数 Google Cloud 资源都是项目的子级。
- 继承:IAM 策略和组织策略自上而下继承。更高级别的拒绝和约束具有优先权。规划资源放置(组织 → 文件夹 → 项目)以最大限度地减少例外和紧急访问需求。
主账号
- Google 账号(用户)、Google 群组、服务账号以及通过 Workload Identity Federation 引入的外部身份。
- 对于人工访问,应将 Google 群组作为主要绑定目标,以简化生命周期变更和审查。
- 服务账号代表应用程序或服务;优先使用工作负载身份而非密钥。
工作负载身份
- 在 Google Cloud 内部:GCE/GAE/Cloud Run/GKE 使用元数据服务器为其附加的服务账号签发短期令牌。
- 在 Google Cloud 外部:Workload Identity Federation 将外部身份(OIDC/SAML/AWS)映射到服务账号,无需使用静态密钥。
设计权衡与故障模式
- 项目杂乱无章且没有文件夹结构,会导致策略重复和漂移。
- 直接向用户授予角色会增加运维负担;优先使用基于群组的绑定。
- 使用具有广泛权限的 Compute Engine 默认服务账号会增加风险;应为每个工作负载创建最小权限的服务账号。
- 将项目错误地放置在不正确的文件夹下会继承错误的策略;应使用标签或通过变更控制谨慎移动项目。
IAM 角色和策略设计
角色类型
- 基本角色 (Viewer, Editor, Owner):权限宽泛,是旧版角色。除非用于严格控制的紧急访问,否则应避免使用。
- 预定义角色:针对每个服务精心策划的角色;大多数用例应优先选择。
- 自定义角色:在组织或项目范围内聚合权限,以满足特定需求。
- 条件角色:IAM Conditions (CEL) 添加上下文,如资源名称、文件夹、标签或时间;用于限制权限强大的角色。
策略原则
- 最小权限:仅在最窄的范围(资源/项目/文件夹)内授予最小所需角色。
- 职责分离:分离职责(例如,网络管理员 vs. 安全管理员 vs. 结算管理员)。不要将部署和批准操作耦合到单个主账号中。
- 继承意识:在组织/文件夹级别的绑定会影响所有后代资源;在应用前记录预期的影响范围。
拒绝策略
- IAM Deny 会显式阻止权限,即使该权限在其他地方被授予;可用于设置护栏(例如,拒绝 iam.serviceAccountKeys.create)。
- 拒绝策略优先;确保有记录在案的紧急访问机制,并配备有时间限制的例外流程。
示例
- 将自定义角色从开发环境复制到生产环境:
gcloud iam roles copy ROLE_ID
–source=projects/DEV_PROJECT
–destination=projects/PROD_PROJECT - 使用 OS Login 授予基于群组的 SSH 管理员权限:
gcloud projects add-iam-policy-binding PROJECT_ID
–member=group:ops-admins@example.com
–role=roles/compute.osAdminLogin
- 将自定义角色从开发环境复制到生产环境:
gcloud iam roles copy ROLE_ID
故障模式
- 在组织或文件夹级别授予的 Editor 角色会无意中级联到所有项目。
- 条件过于严格的条件角色可能会悄无声息地破坏自动化流程;在推广前使用 Policy Troubleshooter 进行测试。
- 自定义角色可能会落后于新增的权限;需定期审查。
结算和成本管理
结算账号和关联
- 对于收费服务,一个项目必须且只能关联到一个结算账号。
- 角色:Billing Account Administrator 管理账号和付款方式;Billing Account User 关联项目;Project Billing Manager 管理项目的结算关联。
- 集中到一个公司结算账号;通过更新项目的结算关联来迁移项目。
预算、提醒和归因
- 预算用于生成提醒,而不是设置支出上限。如果需要强制执行,请使用 Pub/Sub 和 Cloud Functions/Cloud Run 进行程序化修复。
- 将结算数据导出到 BigQuery 以进行每日/每月的成本分析和预测;结合资源标签和标记进行成本归因。
- 标签和标记:标准化键(例如,cost_center、env、app)。缺失标签会降低归因的准确性。
成本分析
- 使用 BigQuery 导出,通过 SQL 按 SKU/服务计算滚动预测。与资源元数据(例如 GCE 标签)联接以进行精细化报告。
- 对于多项目分析,可以聚合所有项目的导出数据,或将数据导出到单个中央数据集中。
常见陷阱
- 未为新项目配置预算;应建立策略,在项目创建时自动创建预算。
- 没有 BigQuery 导出意味着历史洞察力有限;应尽早启用以积累历史数据。
- 在项目上使用个人信用卡会使责任碎片化;应在公司结算账号下统一管理,并配置适当的 IAM 和付款资料。
- 共享服务项目中的成本异常需要通过标签和内部计费策略来解决。
安全工作负载的身份验证和访问模式
- 服务账号模拟
- 优先使用模拟,而不是密钥。将
roles/iam.serviceAccountTokenCreator角色授予调用者身份;调用者获取短期有效的令牌,以服务账号的身份行事。 - 示例:
- 优先使用模拟,而不是密钥。将
undefined
密钥与轮换
- 避免使用用户管理的密钥。如果必须使用,请将其存储在 Secret Manager 中,至少每 90 天轮换一次,监控其使用情况,并使用 VPC Service Controls 和 CMEK 进行限制。
- 强制执行约束以阻止密钥创建:
constraints/iam.disableServiceAccountKeyCreation = true
OS Login 与 SSH
- 使用 OS Login 及基于群组的 IAM 角色(
compute.osLogin,compute.osAdminLogin)。每个用户将自己的公共 SSH 密钥上传到其 Google 账号,以实现可追溯的访问。通过 Admin Activity 和 Data Access 日志进行审计。 - 避免将共享 SSH 密钥烘焙到镜像中。
- 使用 OS Login 及基于群组的 IAM 角色(
Workload Identity Federation
- 对于本地或其他云环境,配置身份联合以授予对 Google Cloud 的访问权限,而无需创建密钥,从而降低数据泄露风险。
故障模式与缓解措施
- 将密钥存储在代码仓库或 CI/CD 变量中会导致泄露;应切换到模拟或联合身份验证。
- 具有宽泛角色的默认服务账号存在风险;应使用
constraints/iam.allowedPolicyMemberDomains进行限制,并移除基本角色。 - 旧版 GCE 实例上缺失访问范围(scope)可能会阻止 API 访问;推荐使用基于每个 API 的 IAM 权限,并结合默认应用凭据。
治理、组织策略、审计与问题排查
组织策略和限制条件
- 使用限制条件强制执行护栏:禁止虚拟机使用外部 IP、限制区域、阻止创建密钥、限制允许的服务、要求统一的存储分区级访问权限、限制网域共享。
- 按资源层次结构定位,并使用标记进行细化,以处理特定于环境的例外情况。
Cloud Identity 和生命周期
- Cloud Identity 提供用户目录、SSO 和管理角色。进行精细的权限委托(例如,群组管理员、用户管理管理员),并自动化员工入职、调动和离职 (JML) 工作流,以更新群组成员资格和访问权限。
- 对敏感环境使用 Access Approvals 和 Access Transparency。
审计日志记录
- 管理员活动 (Admin Activity) 和系统事件 (System Event) 日志始终开启;数据访问 (Data Access) 日志必须显式启用,并可能产生费用。
- 通过将来自文件夹/组织的聚合接收器 (aggregated sinks) 路由到一个安全项目中,实现集中化管理。使用 CMEK 和受限访问来保护该项目。
- 监控策略拒绝 (Policy Denied) 日志,以检测组织策略冲突。
多项目问题排查工具包
- Policy Troubleshooter:根据有效的 IAM 和拒绝策略,诊断访问被允许或拒绝的原因。
- Cloud Asset Inventory:在组织/文件夹/项目范围内查询 IAM 绑定和策略历史记录。
示例:
gcloud asset search-all-iam-policies
–scope=organizations/ORG_ID
–query=‘policy:roles/storage.objectAdmin AND “bucket-name”’ - Logs Explorer:按主账号 (principal)、方法和资源进行筛选,以跨项目跟踪操作。
- 用于操作员上下文切换的 gcloud 配置: gcloud config configurations activate PROD
- 常见故障模式:组织策略冲突导致部署受阻、数据访问日志缺失妨碍调查、以及在错误的范围授予 IAM 权限。建立运行手册 (runbook) 和变更前预览,以降低事件的平均修复时间 (MTTR)。
实际问题场景
Aurelia 零售公司在一次收购后,需要整合多个团队和项目。他们必须集中管理结算,跨数百个 Compute Engine 虚拟机强制执行一致的 IAM 和 SSH 管理,并在最小化中断的前提下建立治理体系。
- 创建公司结算账号并关联项目
- 基本原理:单一结算账号可以集中管理支付方式、赠金和预算。将 Billing Account User 角色授予项目迁移群组,将 Project Billing Manager 角色授予团队负责人,以便在不授予过多权限的情况下重新关联项目。
- 操作:在控制台中创建结算账号。为每个项目更新其结算关联。立即在一个中央分析项目中启用结算数据导出至 BigQuery。
- 使用文件夹和标记标准化资源层次结构
- 基本原理:将项目置于环境文件夹(prod、nonprod)下,支持护栏的继承和有针对性的例外。标记允许进行细粒度的组织策略定位,而无需复制文件夹树。
- 操作:为生产 (prod) 和非生产 (nonprod) 环境创建文件夹;相应地移动项目。定义标记
env=prod|nonprod和应用标识符。
- 实施基于群组的 IAM,遵循最小权限和职责分离原则
- 基本原理:群组简化了生命周期管理和审计。在部署人员、安全人员和网络管理员之间分离角色可以减少爆炸半径。
- 操作:为应用操作员 (app-operators)、网络管理员 (net-admins)、安全管理员 (sec-admins) 和结算管理员 (billing-managers) 创建 Google 群组。根据需要在文件夹/项目范围绑定预定义角色;避免使用基本角色。
- 强制执行基于 OS Login 的 SSH 管理
- 基本原理:附加到用户账户的独立 SSH 密钥提供了可追溯、可撤销的访问权限。OS Login 角色通过 IAM 管理 Linux 账户,从而消除了共享密钥。
- 操作:在每个项目中,启用 OS Login 元数据。将
compute.osAdminLogin角色授予运维管理员群组。 示例: gcloud compute project-info add-metadata
–metadata enable-oslogin=TRUE
- 使用模拟 (impersonation) 取代服务账号密钥
- 基本原理:短期凭证可降低密钥泄露风险并简化轮换。审计日志会捕获谁模拟了谁,从而提高可追溯性。
- 操作:将
roles/iam.serviceAccountTokenCreator角色授予 CI/CD 运行器身份,使其能够模拟工作负载服务账号。移除用户管理的密钥,并应用组织策略以阻止创建新密钥。
- 应用组织策略作为护栏
- 基本原理:限制条件可防止所有项目中出现有风险的配置,同时允许在有正当理由的情况下通过标记设置例外。
- 操作:强制执行限制条件,以禁止生产环境中的外部 IP、将区域限制在批准的地点,并禁用服务账号密钥创建。使用标记为有文档化批准的特定项目允许例外。
- 建立成本治理
- 基本原理:预算可在超支前向所有者发出警报;导出到 BigQuery 的数据可用于成本归因和预测。标签和标记可将资源支出映射到成本中心。
- 操作:为每个文件夹和主要应用创建预算,并设置 Pub/Sub 通知。通过部署模板和 CI 中的策略验证来强制执行标签策略。
- 集中审计并加速问题排查
- 基本原理:跨整个组织的聚合日志记录和资产清单可以加快调查和合规性报告的速度。
- 操作:创建聚合接收器,将日志发送到受 CMEK 保护的存储分区的安全项目中。为关键服务(Cloud Storage、BigQuery)启用数据访问日志。使用 Cloud Asset Inventory 定期扫描 IAM 绑定。培训操作员在访问失败时使用 Policy Troubleshooter,并使用 Logs Explorer 跟踪管理员活动/数据访问。
- 通过预览和分阶段部署来实施变更
- 基本原理:在强制执行前验证 IAM 和策略的效果可减少服务中断。
- 操作:首先在非生产环境中测试 IAM 和组织策略。在可用时使用空运行 (dry-run) 和策略模拟。对于部署自动化,实施金丝雀部署和回滚计划。
这种方法实现了集中的结算和成本洞察、通过 OS Login 实现的可追溯的 SSH 管理、使用模拟的最小权限 IAM、通过组织策略实现的强大预防性控制,以及在新的多项目环境中稳健的审计和问题排查能力。
所有领域 · Compute Engine 和虚拟机操作 →
练习这些题目 → · 在 ExamRoll.io 上限时练习 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通过考试 →