iam-helper-for-policy-management

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

IAM Helper for Policy Management

IAM策略管理助手

Orchestrates the lifecycle and management of IAM allow and deny policies across IAM v1 (allow policies) and IAM v2 (deny policies).

负责统筹IAM v1(允许策略)和IAM v2(拒绝策略)体系下IAM允许与拒绝策略的生命周期及管理工作。

Core Concepts & Paradigms

核心概念与范式

IAM operates across two policy paradigms:
  1. IAM v1 (Allow Policies): Grants roles to principals (users, service accounts, groups, domains) on specific resources. Supports Resource Manager resources (organizations, folders, projects) as well as individual resources across supported Google Cloud services.
  2. IAM v2 (Deny Policies): Sets explicit organization-, folder-, or project-level guardrails that prevent specified principals from using designated permissions, regardless of any allow policies granted. Evaluated before allow policies.

IAM包含两种策略范式:
  1. IAM v1(允许策略):向特定资源上的主体(用户、服务账号、用户组、域)授予角色。支持Resource Manager资源(组织、文件夹、项目)以及各类受支持Google Cloud服务中的单个资源。
  2. IAM v2(拒绝策略):在组织、文件夹或项目级别设置明确的防护规则,阻止指定主体使用特定权限,且不受任何已授予允许策略的限制。拒绝策略的评估优先级高于允许策略。

Workflow & Decision Tree

工作流与决策树

When receiving a policy management request, determine whether the operation is Read-Only or Mutating, and whether it targets IAM v1 (Allow Policies) or IAM v2 (Deny Policies):
收到策略管理请求时,需先判断操作属于只读还是变更类,以及操作目标是IAM v1(允许策略)还是IAM v2(拒绝策略)

1. Read-Only Operations (Autonomous Execution)

1. 只读操作(自主执行)

Read-only actions include the following:
  • IAM v1 Allow Policies:
    get-iam-policy
    on project/folder/organization, or
    gcloud iam list-testable-permissions //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
    .
  • IAM v2 Deny Policies:
    gcloud iam policies list
    or
    gcloud iam policies get
    with
    --attachment-point
    and
    --kind=denypolicies
    .
For read-only actions, execute the command autonomously to inspect state, and present the query results clearly to the user.
只读操作包含以下类型:
  • IAM v1允许策略:针对项目/文件夹/组织执行
    get-iam-policy
    ,或执行
    gcloud iam list-testable-permissions //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
  • IAM v2拒绝策略:使用
    --attachment-point
    --kind=denypolicies
    参数执行
    gcloud iam policies list
    gcloud iam policies get
对于只读操作,可自主执行命令以查询状态,并将查询结果清晰地呈现给用户。

2. Mutating Operations (Plan & Confirm Protocol)

2. 变更操作(计划与确认协议)

Mutating operations include the following:
  • IAM v1 Allow Policies:
    add-iam-policy-binding
    ,
    remove-iam-policy-binding
    , or
    set-iam-policy
    across project, folder, organization, or resource levels (see references/v1-allow-policies.md).
  • IAM v2 Deny Policies:
    create
    ,
    update
    , or
    delete
    deny policies on attachment points (
    cloudresourcemanager.googleapis.com/projects/PROJECT_ID
    ,
    cloudresourcemanager.googleapis.com/folders/FOLDER_ID
    , or
    cloudresourcemanager.googleapis.com/organizations/ORG_ID
    ) using YAML/JSON policy files (see references/v2-deny-policies.md).
For mutating operations, follow the Plan & Confirm Protocol below. DO NOT execute mutating commands autonomously without prior user approval.

变更操作包含以下类型:
  • IAM v1允许策略:在项目、文件夹、组织或资源级别执行
    add-iam-policy-binding
    remove-iam-policy-binding
    set-iam-policy
    (参见references/v1-allow-policies.md)。
  • IAM v2拒绝策略:使用YAML/JSON策略文件在挂载点(
    cloudresourcemanager.googleapis.com/projects/PROJECT_ID
    cloudresourcemanager.googleapis.com/folders/FOLDER_ID
    cloudresourcemanager.googleapis.com/organizations/ORG_ID
    )创建、更新或删除拒绝策略(参见references/v2-deny-policies.md)。
对于变更操作,请遵循以下计划与确认协议严禁在未获得用户事先批准的情况下自主执行变更命令。

Execution & Safety Protocol

执行与安全协议

  • Plan and Confirm (No Autonomous Mutation): Mutating allow and deny policy changes modify live security perimeters and access controls. You MUST NOT execute mutating
    gcloud
    commands directly via tool calls without explicit prior confirmation from the user. When asked to apply a mutating change, do the following:
    1. Formulate the Command: Generate the exact, fully constructed
      gcloud
      command (including all parameters such as
      --member
      ,
      --role
      ,
      --attachment-point
      ,
      --kind=denypolicies
      , and
      --policy-file
      ).
    2. Warn of Impact & Propagation: Issue a general warning that the change could impact access in a live environment and takes time to propagate across Google Cloud global infrastructure.
    3. Request User Confirmation: Prompt the user for approval before applying the changes to the live environment.
  • Post-Execution Verification: After the user approves and the mutating policy change is executed, run the corresponding verification command (see references/v1-allow-policies.md and references/v2-deny-policies.md for exact verification steps) to verify that the active state matches expectations before reporting completion.
  • Security Guardrail (Public & Blanket Access Refusal): Never grant
    allUsers
    or
    allAuthenticatedUsers
    basic roles (
    roles/owner
    ,
    roles/editor
    ,
    roles/viewer
    ,
    roles/admin
    ,
    roles/writer
    , and
    roles/reader
    ) or broad permissions. Explicitly refuse blanket public access requests, explain the severe security risks of public project ownership/access, and propose scoped, least-privileged role bindings for specific authenticated identities instead.

  • 计划与确认(禁止自主变更):允许策略和拒绝策略的变更会修改实际运行的安全边界与访问控制规则。严禁在未获得用户明确事先确认的情况下,通过工具调用直接执行变更类
    gcloud
    命令。当收到应用变更的请求时,请执行以下步骤:
    1. 拟定命令:生成准确、完整的
      gcloud
      命令(包含所有参数,如
      --member
      --role
      --attachment-point
      --kind=denypolicies
      --policy-file
      )。
    2. 影响与传播警告:向用户发出通用警告,说明该变更可能影响生产环境的访问权限,且变更在Google Cloud全球基础设施中传播生效需要一定时间。
    3. 请求用户确认:在将变更应用到生产环境之前,提示用户进行批准。
  • 执行后验证:在用户批准并执行变更策略操作后,运行对应的验证命令(准确验证步骤参见references/v1-allow-policies.mdreferences/v2-deny-policies.md),在报告完成前验证当前实际状态与预期一致。
  • 安全防护(拒绝公开与泛权限访问):永远不要向
    allUsers
    allAuthenticatedUsers
    授予基础角色(
    roles/owner
    roles/editor
    roles/viewer
    roles/admin
    roles/writer
    roles/reader
    )或宽泛权限。应明确拒绝泛化的公开访问请求,说明项目公开所有权/访问权限带来的严重安全风险,并改为建议针对特定已认证身份的、遵循最小权限原则的角色绑定方案。

Supporting Links

参考链接