实验 07 审计与故障排查#

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

先准备证据#

管理员在实验项目 IAM & Admin 的 Audit Logs 中，为 Cloud Storage 与 Secret Manager 启用实验所需 Data Read；需要追踪输出写入时也启用对应 Data Write。记录原配置和 exemptions，避免用豁免身份验证。Admin Activity 与 Data Access 是不同类别，后者多数默认未启用。

Logging Viewer 不等于能读 Data Access audit logs。 排查身份按需授予 Private Logs Viewer，不能为了排障扩大 QA 长期权限；先确认日志已启用，记录量可能计费。

正常调用留证#

QA 调用 /report，记录响应中的 request_id、报表路径与调用时间。在 Logs Explorer：

检查 cloud_run_revision 应用日志中的 request_id 和 stage=complete。
检查 Cloud Storage 审计日志，按运行 SA、时间、对象资源缩小范围。
检查 Secret Manager 的访问事件。不要把 Secret 内容复制到实验记录。

可从以下过滤条件开始，再用实际日志字段细化：

protoPayload.authenticationInfo.principalEmail="REPLACE_RUNTIME_SA_EMAIL"

日志中的 methodName、resourceName、status 和 authenticationInfo 用于解释请求。不同服务和失败类型的字段及记录行为不同，找不到日志并不能直接证明“没有发生操作”。应用 request_id 不是自动出现在所有下游审计日志中的关联 ID；本案例结合时间、身份和唯一报表对象名关联。

注入一个可恢复故障#

管理员只移除运行 SA 对输入 Bucket 的 Viewer 绑定：

gcloud storage buckets remove-iam-policy-binding "gs://$INPUT_BUCKET" \
  --member="serviceAccount:$APP_SA" --role=roles/storage.objectViewer

QA 重新调用，预期应用返回 stage=read_input 与错误类型。外层应用返回 500，而实际 Google API 拒绝可能是 PermissionDenied；两层错误要分开看。

管理员在 Policy Troubleshooter 输入：运行 SA、实际 Bucket 对象资源、storage.objects.get。也可从对应审计日志进入排查以带入上下文。检查缺失 Allow、其他组或继承路径、Conditions 与 Deny。排查者需要能读取相关策略，否则工具结果可能不完整。

恢复同一条最小授权：

gcloud storage buckets add-iam-policy-binding "gs://$INPUT_BUCKET" \
  --member="serviceAccount:$APP_SA" --role=roles/storage.objectViewer

等待传播后重试，应恢复成功。不要通过给整个项目 Editor 掩盖错误。

故障题库#

现象	应先检查什么	修复方向
CLI 成功，本地 Python 失败	ADC 与 CLI 真实身份、quota project	修正应用凭据或对应消费权限
QA 调用成功，读取输入失败	Cloud Run 运行 SA 与输入资源	修复运行身份或 Bucket 授权
从用户移除角色后仍成功	组、父级、其他绑定	撤销真正授予权限的路径
临时授权到期后仍成功	是否存在无条件同等授权	清理另一条路径
Allow 存在但读取失败	Deny、条件、实际目标	修正规则或请求，不盲目加角色
创建 SA 密钥失败	IAM 权限、有效组织约束	采用无密钥方案，分辨拒绝来源
变更后结果短期不一致	策略与组传播、旧凭据	记录时间并等待合理传播

每次只注入一项故障，记录并恢复后再做下一项。环境没有配置的策略不能被臆测为故障原因。

验收：用一页实验记录说明真实身份、权限、资源、策略来源、日志证据、修复与复测。Policy Troubleshooter 不是覆盖网络限制、所有服务 ACL 和应用授权的万能工具。

参考：Cloud Audit Logs、排查权限、权限传播。