实验 06 条件授权与安全约束#

验证：未记录

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

三项实验分别解释“何时允许”“明确拒绝什么”“哪些配置受到组织限制”。一次只改变一种机制，便于定位原因。

临时日志访问#

场景：Bob 需要短时间查看实验项目的普通日志。前提：Bob 没有从其他组或父级获得同等日志查看权，项目已有日志。配置者需要项目 IAM 修改权。

在教程根目录运行：

export EXPIRY=$(python3 -c 'from datetime import datetime,timedelta,timezone; print((datetime.now(timezone.utc)+timedelta(minutes=5)).strftime("%Y-%m-%dT%H:%M:%SZ"))')
export CONDITION="expression=request.time < timestamp('$EXPIRY'),title=lab-expiring-logs,description=Five-minute lab access"
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="user:$DEV_EMAIL" --role=roles/logging.viewer --condition="$CONDITION"

Bob 在独立会话执行：

gcloud logging read 'logName:"cloudaudit.googleapis.com%2Factivity"' \
  --project="$PROJECT_ID" --limit=5

生效后预期允许，到期后重新请求预期拒绝。五分钟只是教学窗口，若权限传播消耗了时间，可移除旧绑定后重新设置更长窗口。返回空结果与权限拒绝不同；先由管理员确认匹配日志确实存在。

到期只使条件不成立，绑定并未自动被删除。管理员在原终端清理，或从策略读取完全相同的条件：

gcloud projects remove-iam-policy-binding "$PROJECT_ID" \
  --member="user:$DEV_EMAIL" --role=roles/logging.viewer --condition="$CONDITION"

验证陷阱：如果给 Bob 另加一个无条件的同等角色，到期后他仍能访问。完成后移除额外绑定。审批与到期是不同能力，Conditions 本身不是申请审批系统。

Deny 阻断已有 Allow#

业务设计中可防止普通人员删除生产项目；为了无破坏地验证优先级，本实验改为暂时禁止运行 SA 读取对象。只在独立实验项目附加策略，不能复制到真实组织根节点。

前提：第 05 章应用已成功；配置者拥有相应 Deny 管理权限。仅设置运行 SA 为拒绝主体，不影响负责恢复的管理员。

生成模板实例，模板中的 API 权限格式与普通 Permission 不同：

python3 - <<'SCRIPT'
import json, os
from pathlib import Path
p=json.loads(Path('templates/deny-read.json').read_text())
p['rules'][0]['denyRule']['deniedPrincipals']=[
    'principal://iam.googleapis.com/projects/-/serviceAccounts/'+os.environ['APP_SA']]
Path('deny-read.local.json').write_text(json.dumps(p,indent=2))
SCRIPT
export PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" --format='value(projectNumber)')
export ATTACHMENT="cloudresourcemanager.googleapis.com/projects/$PROJECT_NUMBER"
gcloud iam policies create lab-deny-read --attachment-point="$ATTACHMENT" \
  --kind=denypolicies --policy-file=deny-read.local.json

仍由 QA 调用应用。预期：调用 Cloud Run 的认证成功，应用在 read_input 阶段返回错误。输入 Bucket 的 Allow 绑定仍在，但 storage.googleapis.com/objects.get 被拒绝。应用样例对内部失败返回 HTTP 500，不能把外层状态码直接当成 Storage API 的状态码。

管理员撤销本实验策略后，重复调用应恢复：

gcloud iam policies delete lab-deny-read --attachment-point="$ATTACHMENT" --kind=denypolicies

拓展推演：Deny exception 只排除该规则，不能提供缺失的 Allow。Deny 条件支持范围不同于 Allow Conditions，不能把上述时间条件直接照搬进 Deny。

Organization Policy 禁止创建 SA 密钥#

场景：公司要求应用使用环境凭据或短期令牌。配置者需要适当范围的 Organization Policy Admin，组织应允许在实验项目做该实验。

在 Console 选中实验项目，打开 Organization Policies，检查禁止创建服务账号密钥的约束及其有效策略。传统约束名为 iam.disableServiceAccountKeyCreation；环境还可能有对应 managed 约束。先记录两者及父级策略，不假定默认未启用。
若有效策略已经禁止，保留现状，直接验证即可。若允许且实验支持配置，在项目上创建禁止策略。templates/org-policy-key.yaml 展示传统约束的配置结构；填写 Project Number 后可作为配置参考。
使用拥有 SA Key Admin 等密钥创建权限的独立实验管理身份，在目标实验 SA 的 Keys 页面尝试创建 JSON 密钥。预期被组织策略拒绝。缺少 IAM 权限导致的拒绝不能用作该实验成功的证据。
若操作意外成功，说明策略未生效或目标不正确：立即删除刚创建的云端密钥和本地下载文件，再排查有效策略，不保存密钥作为教程成果。
再次调用 Cloud Run，预期仍成功。绑定运行 SA 不依赖用户管理的 JSON 密钥。
仅恢复本实验新建的项目级覆盖；此前已经存在的组织约束保持不变。不要为了“回滚”关闭父级本来就有的保护。

禁止新建 SA key 不会吊销已有 key。 本实验只验证创建约束；实际撤权仍需审查并删除相关已有 key，以及密钥上传等其他路径。

验收#

逐项写出：策略附着位置、目标主体、受控操作、预期失败的层、恢复方法。不得仅凭一个 403 判断它是 Deny、条件到期还是组织策略。

参考：Conditions、Deny 创建、支持权限、SA 组织约束。