IAM：授权验证与撤权排障

验证：未记录

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

用无其他授权的测试身份区分 impersonation 权限与目标资源权限。

常用操作#

替换为实际资源；本段不依赖 lab.env。

BUCKET='REPLACE_BUCKET'

gcloud auth list --filter=status:ACTIVE
gcloud config get-value auth/impersonate_service_account
gcloud storage buckets get-iam-policy "gs://$BUCKET"

容易踩的坑#

只有目标操作因缺少预期 permission 被拒绝，才证明权限边界有效。 网络超时、token 过期、对象不存在或无法 impersonate，都不能代替读写权限的拒绝测试。

撤 Token Creator / Group membership 与撤资源权是不同动作，已签发凭据另需验证。

配置说明与完整示例（按需展开）

前置概念：IAM 授权模型。本实验区分“用户能否 impersonate SA ”和“SA 能否访问 Bucket”，并验证限时授权与撤权。

前置：环境篇。操作者需要创建 SA、管理这个 Bucket 及其 IAM、管理 SA IAM 的权限。使用没有其他项目 role 的新 SA，避免继承权限干扰。

1. 确认操作者身份#

本例管理操作使用 gcloud auth login 保存的用户凭据；读取/写入测试显式 impersonate lab-reader。先检查实际身份及默认 impersonation：

gcloud auth list
gcloud config get-value account
gcloud config get-value auth/impersonate_service_account

预期 account 为操作者邮箱，auth/impersonate_service_account 未设置；若使用其他凭据来源，先确认调用身份，不能只看 account 属性。

本实验中的操作	访问资源时使用的身份	凭据来源
创建 SA、创建 Bucket、上传测试文件、添加或移除绑定	操作者的用户账号	`gcloud auth login` 获得的用户凭据
带 `--impersonate-service-account="$READER"` 的读取和写入测试	`lab-reader` Service Account	操作者先以用户身份申请该 SA 的短期凭据，再以 SA 身份访问 Bucket

impersonate reader 后只检查 reader 权限，不叠加操作者写权限。 操作者需在 reader 上有 Token Creator，reader 则在 Bucket 上有 Object Viewer；无需 SA key。impersonation

本地 SDK 的 ADC 与 CLI 凭据分开，见本地认证。

2. 创建资源、读写与撤权#

source lab.env
gcloud services enable storage.googleapis.com iamcredentials.googleapis.com
export IAM_BUCKET="${PROJECT_ID}-iam-lab"
export READER="lab-reader@${PROJECT_ID}.iam.gserviceaccount.com"
export HUMAN_EMAIL=$(gcloud config get-value account)

gcloud iam service-accounts create lab-reader
gcloud storage buckets create "gs://$IAM_BUCKET" --location="$REGION" --uniform-bucket-level-access --public-access-prevention
printf 'hello IAM\n' > iam-example.txt
gcloud storage cp iam-example.txt "gs://$IAM_BUCKET/example.txt"
gcloud storage buckets add-iam-policy-binding "gs://$IAM_BUCKET" --member="serviceAccount:$READER" --role=roles/storage.objectViewer
# 在 Service Account $READER 上，授予用户 $HUMAN_EMAIL 签发该账号短期凭据的权限，使其可通过 --impersonate-service-account 以该 Service Account 身份调用 API；此命令本身不授予 Bucket 访问权限。
gcloud iam service-accounts add-iam-policy-binding "$READER" --member="user:$HUMAN_EMAIL" --role=roles/iam.serviceAccountTokenCreator

# 成功：读取
 gcloud storage cat "gs://$IAM_BUCKET/example.txt" --impersonate-service-account="$READER"
# 预期失败：没有 storage.objects.create
 gcloud storage cp iam-example.txt "gs://$IAM_BUCKET/denied.txt" --impersonate-service-account="$READER"

IAM 变更传播可能延迟；等待后重试，别用追加 Owner 解决。

gcloud storage buckets remove-iam-policy-binding "gs://$IAM_BUCKET" --member="serviceAccount:$READER" --role=roles/storage.objectViewer
# 传播完成后应失败
 gcloud storage cat "gs://$IAM_BUCKET/example.txt" --impersonate-service-account="$READER"

验收：保存两次拒绝结果，指出拒绝的是 impersonation 还是对象访问。短期 token 尚未过期也不意味着被撤销的资源权限仍永久有效。

3. 限时授权#

继续使用前面的 READER 与 Bucket，为读权限设置五分钟有效期：

export EXPIRES=$(python3 -c 'from datetime import datetime,timedelta,timezone; print((datetime.now(timezone.utc)+timedelta(minutes=5)).strftime("%Y-%m-%dT%H:%M:%SZ"))')
gcloud storage buckets add-iam-policy-binding "gs://$IAM_BUCKET" --member="serviceAccount:$READER" --role=roles/storage.objectViewer --condition="title=temporary-read,expression=request.time < timestamp('$EXPIRES')"
gcloud storage cat "gs://$IAM_BUCKET/example.txt" --impersonate-service-account="$READER"

生效后能读取；五分钟后再次读取应被拒绝。若仍能读取，检查是否存在其他无条件或从 Project / Folder / Organization 继承的授权。到期不会自动删除 binding，只是条件不再满足；最终清理 Bucket 会删除该资源上的绑定。

4. 撤权要区分三个层次#

动作	作用与边界
撤人员组、 federated identity 信任或 Token Creator	阻止后续取得身份；不要假设所有已签发凭据随即失效
撤资源上的访问授权	对该资源的后续访问重新受权限判断；需要考虑传播、继承和其他授权路径
撤数据库密码/外部 API token	在实际签发方处理；删除 Secret 版本不能替代该动作，存量连接可能另需终止

撤权前保存允许访问的 Principal、资源和时间；撤权后分别用已有凭据和新登录重测相同操作，并确认失败是资源权限拒绝。Cloud Run 等托管服务还有实际运行 SA 与业务自己的认证层，不能只看操作者 CLI 退出登录。

分开人员、发布、运行时和应急身份；高权限应急身份限时、告警、事后回收，并验证正常身份系统故障时的恢复入口。流水线撤权、凭证轮换。

5. 企业落地与排障#

团队通过组授权；dev/staging/prod 分项目；每个工作负载独立 SA；部署者和运行者分离；生产提权限时；Data Access 审计按服务启用并评估费用。

403 排查顺序：

gcloud auth list、ADC、运行 SA：真正调用者是谁？
检查资源完整路径、项目、目标 permission。
查看目标资源及所属 Project / Folder / Organization 的 Allow、Deny、Condition；不要只看项目本地 policy。
用 IAM Policy Troubleshooter 验证对应 Principal、资源和权限。
检查 API、Organization Policy、VPC Service Controls，再检查网络。
在审计日志查 principalEmail、authorizationInfo；联合/ impersonation 身份还要查看委派链。

6. 清理#

如果继续做外部凭据文件实验，先保留 Bucket 和测试对象，完成后再清理：

gcloud storage rm --recursive "gs://$IAM_BUCKET"
gcloud iam service-accounts delete "$READER"
rm iam-example.txt

继续：无密钥 CI 实验、GKE 工作负载身份、IAP 员工登录、KMS 密钥权限。