故障应急"临时提权"的工程闭环：分钟级申请 + 秒级生效 + 自动过期 + 全程审计，有没有一套可复现方案？

结论先行：JIT 提权的本质是"把长期 RoleBinding 换成短 TTL 凭证 + 事件触发授予 + 到期自动回收 + 全程审计"四件事的流水线，不需要一个完美平台，6 人团队一周能落地的最小闭环是：Vault 发短 TTL token → 一个 50 行的 cron 脚本到点回收 → 审计日志进 Loki/ELK。K8s 和 DB 两条线分开做，先做 K8s（因为你们上次被审计点名的就是 K8s 那条线）。

下面按你列的 5 个期望逐条给可落地的东西。

一、参考架构：一个 Vault + 两条回收线

┌──────────┐     ┌──────────────┐     ┌─────────────────────────────┐
│  申请人   │────▶│  审批网关     │────▶│  Vault (token 颁发中心)      │
│ (SRE/DBA)│     │ (P0 快速通道) │     │  · K8s: 短期 SA token       │
└──────────┘     │ (日常慢通道)  │     │  · DB: 短期 GRANT 凭证       │
                 └──────────────┘     └──────────┬──────────────────┘
                                                 │ 自动过期 (TTL)
                                                 ▼
                                    ┌─────────────────────────────┐
                                    │  回收器 (cron / K8s CronJob) │
                                    │  · 扫 Vault token 过期时间    │
                                    │  · 到点 revoke / revoke GRANT │
                                    │  · 写审计日志                  │
                                    └─────────────────────────────┘
                                                 │
                                                 ▼
                                    ┌─────────────────────────────┐
                                    │  审计日志 → Loki / ELK / SIEM │
                                    └─────────────────────────────┘

核心原则：所有临时权限的"生命周期"由 Vault 统一管理，不依赖人记得删。 你上次那个 SA 挂了 3 天 cluster-admin 的事故，根因就是"授予和回收是两个人、两个流程"。

1.1 Vault 侧配置（K8s 场景）

# vault: K8s 短期 SA token 的 auth 后端
# 前提：Vault 部署在集群内，用 serviceaccount 注入
# 这里用一个简单的 token store 模拟 JIT 提权

# 1) 创建 policy：只允许 SRE 角色申请临时 cluster-admin
policy "jit-sre-cluster-admin" {
  path "auth/token/lookup-self" {
    capabilities = ["read"]
  }
}

# 2) P0 快速通道：预设一个"应急 token"，TTL 10 分钟，
#    只有 SRE 角色能取（通过 Vault AppRole 限制）
#    平时不存在，P0 时由审批网关触发创建

实操流程（P0 快速通道，目标 < 2 分钟）：

# 步骤 1：SRE 在 IM 群发 /p0 命令（或点飞书/钉钉 bot 按钮）
# 步骤 2：审批 bot 自动 @值班 leader，leader 点"同意"（或 90s 无拒绝自动通过）
# 步骤 3：bot 调 Vault API 创建短期 token
curl -s -X POST https://vault.internal:8200/v1/auth/token/create \
  -H "X-Vault-Token: $VAULT_APPROLE_TOKEN" \
  -d '{
    "policies": ["cluster-admin-jit"],
    "ttl": "600s",
    "display_name": "jit-sre-'$(date +%s)'",
    "meta": {
      "incident_id": "INC-2026-0412",
      "requester": "sre-zhang",
      "approver": "leader-li",
      "reason": "kill long-running transactions on payment-db"
    }
  }'
# 返回的 token 直接给 SRE，他拿这个 token 配 kubectl 用
# kubectl 用法：
# export KUBECONFIG=/dev/stdin
# echo "apiVersion: v1
# kind: Config
# clusters:
# - cluster: {server: https://k8s-apiserver:6443}
#   name: prod
# contexts:
# - context: {cluster: prod, user: jit-sre}
#   name: prod
# current-context: prod
# users:
# - name: jit-sre
#   user: {token: <vault-returned-token>}" | kubectl config view --flatten -o yaml > /tmp/jit-kubeconfig
# kubectl --kubeconfig /tmp/jit-kubeconfig exec -it payment-pod -- mysql -e "KILL 12345;"

关键设计点：

• TTL 600s（10 分钟），到期 Vault 自动 revoke，不需要任何人记得删
• meta 字段就是审计留痕的最小字段集（见第三部分）
• P0 快速通道的"审批"是 IM bot 的 90s 自动通过，不是走工单系统——P0 场景 18 分钟审批不可接受

1.2 Vault 侧配置（MySQL 场景）

MySQL 没有原生 "GRANT WITH EXPIRE"（8.0 没有），所以用外部调度器到点 REVOKE：

-- 提权时（由 Vault 触发，或通过审批网关）
GRANT PROCESS, SUPER ON *.* TO 'jit_dba'@'10.0.%' IDENTIFIED BY 'tmp_<random>' REQUIRE SSL;
GRANT SELECT, PROCESS ON payment_db.* TO 'jit_dba'@'10.0.%';

-- 回收时（CronJob 到点执行）
REVOKE PROCESS, SUPER ON *.* FROM 'jit_dba'@'10.0.%';
REVOKE SELECT, PROCESS ON payment_db.* FROM 'jit_dba'@'10.0.%';
DROP USER 'jit_dba'@'10.0.%';

# K8s CronJob：每分钟扫一次"待回收"的 JIT DB 账号
apiVersion: batch/v1
kind: CronJob
metadata:
  name: jit-db-revoke
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: revoke
            image: internal/jit-revoke:latest
            env:
            - name: VAULT_ADDR
              value: https://vault.internal:8200
            - name: MYSQL_ADMIN_PASS
              valueFrom:
                secretKeyRef: {name: mysql-admin, key: pass}
            # 逻辑：
            # 1. 查 Vault KV 里 jit-db-accounts 路径下所有记录
            # 2. 每条记录有 expire_at 字段
            # 3. 当前时间 > expire_at → 连 MySQL 执行 REVOKE + DROP USER
            # 4. 写审计日志到 Loki
            # 5. 把 Vault KV 里该条标记为 revoked
          restartPolicy: OnFailure

你踩过的"忘了删"坑，这里用两层保险防住：

1. 主保险：CronJob 每分钟扫，到点自动 REVOKE——不依赖人
2. 副保险：MySQL 侧加一个 event 兜底（万一 CronJob 挂了）：

CREATE EVENT evt_jit_cleanup
ON SCHEDULE EVERY 5 MINUTE
DO
  -- 查 information_schema.user_privileges 里
  -- 用户名匹配 'jit_%' 且创建时间 > 15 分钟的，DROP USER
  -- （注意：这个 event 本身需要 EVENT 权限，用最小权限的 admin 账号建）

二、自动过期的实现细节与"连接池残留"坑

2.1 各层过期的实现方式

| 层级 | 过期机制 | 实现 | |------|---------|------| | K8s SA token | Vault token TTL（600s） | 到期后 token 自动失效，apiserver 拒绝请求 | | K8s RoleBinding | 不建议用（没有原生 TTL） | 改用 token 过期后 SA 本身还在但无权限，等效回收 | | MySQL GRANT | 外部 CronJob 到点 REVOKE | 5 分钟兜底 event | | 云 RAM | STS DurationSeconds | 原生支持，不用额外做 |

2.2 "过期了但连接池里老连接还在"——你一定会踩的坑

K8s 侧：token 过期后，已建立的 gRPC/HTTP2 长连接不会立刻断开。apiserver 默认 --request-timeout=60s，所以已建立的连接最多再活 60s 就会因为下一次请求被 401 拒绝。如果你用 kubectl exec 开了一个 shell，那个 shell 不会自动断开，但任何新命令都会 401。实操建议：在 JIT 流程结束前，SRE 主动 exit 退出 exec 会话。

MySQL 侧：更隐蔽。REVOKE 只影响新连接，已建立的连接（连接池里的）继续持有旧权限直到连接断开。如果你用的是连接池（HikariCP），默认 maxLifetime=30min，意味着回收后最多 30 分钟内，池里的老连接还能用旧权限。

解决：

# REVOKE 之后，主动 kill 该用户的所有连接
mysql -u admin -p -e "
  SELECT CONCAT('KILL ', id, ';') 
  FROM information_schema.processlist 
  WHERE user = 'jit_dba';
" | mysql -u admin -p

# 或者更暴力：
mysql -u admin -p -e "
  SET GLOBAL max_connections = 0;  -- 不行，会影响所有人
"
# 正确做法：
mysql -u admin -p -e "
  SELECT id FROM information_schema.processlist WHERE user='jit_dba';
" | while read -r pid; do
  mysql -u admin -p -e "KILL $pid"
done

把这段逻辑写进 CronJob 的 revoke 脚本里：先 REVOKE，再 KILL 该用户的所有连接，最后 DROP USER。

三、审计留痕的最小字段集

等保 2.0 三级对"特权账号操作"的留痕要求，最小字段集：

{
  "timestamp_utc": "2026-04-12T08:32:15.123Z",
  "session_id": "jit-20260412-003",
  "requester": {
    "id": "sre-zhang",
    "role": "sre-oncall"
  },
  "approver": {
    "id": "leader-li",
    "role": "tech-lead",
    "approved_at": "2026-04-12T08:32:10.000Z"
  },
  "resource": {
    "type": "k8s | mysql | redis | cloud-ram",
    "target": "payment-db / cluster-admin / schema:payment",
    "permissions_granted": ["SELECT", "PROCESS"]
  },
  "reason": {
    "incident_id": "INC-2026-0412",
    "description": "kill 3 long-running transactions causing payment 5xx"
  },
  "duration": {
    "ttl_seconds": 600,
    "actual_seconds": 245,
    "revoked_at": "2026-04-12T08:36:20.000Z",
    "revoke_method": "auto_cronjob | manual"
  },
  "actions": [
    {"ts": "08:32:20", "cmd": "mysql -e 'SHOW PROCESSLIST'"},
    {"ts": "08:32:45", "cmd": "mysql -e 'KILL 12345'"},
    {"ts": "08:33:10", "cmd": "mysql -e 'KILL 12346'"}
  ]
}

打通方式：

• Vault 的 audit log（vault audit enable file file_path=/var/log/vault-audit.log）→ Filebeat → ELK/Loki
• K8s 侧：apiserver 的 --audit-log-path 已经记录了所有 401/403 和特权操作，直接接 EFK
• MySQL 侧：general_log=ON（只在 JIT 窗口内开，平时关，否则性能扛不住）→ 或者用 mysql-binlog-adapter 接 binlog
• 汇总到 SIEM：等保 2.0 三级要求日志保存 ≥ 6 个月，Loki 设 retention 180 天

关键：actions 字段里的每一条命令，如果是 K8s 侧从 apiserver audit log 取，如果是 MySQL 侧从 general_log 取。不要自己写日志——用系统原生的审计通道，否则审计方不认。

四、各工具链的坑（我踩过的）

4.1 Vault

• 坑 1：token_policies 的 policy 粒度不够细。Vault policy 是 path 级别的，不是 K8s RBAC 的 resource+verb 级别的。解决：Vault 只负责"发 token"，实际权限还是走 K8s RBAC 的 RoleBinding，Vault token 绑到一个专用的 SA，这个 SA 的 RoleBinding 指向窄权限的 Role。
• 坑 2：Vault HA 模式下，token revoke 是异步的（raft 复制），极端情况下 revoke 后 1-2s 内 token 还能用。对 P0 场景可接受，但要知道这个窗口。
• 坑 3：Vault 的 AppRole 如果 secret_id_ttl 设得太长（比如 7 天），等于给了一个"长期凭证"，违背 JIT 初衷。secret_id_ttl 必须 ≤ 1h，token_ttl 按场景设（P0 10min / 日常 30min）。

4.2 K8s RBAC

• 坑 1（你踩过的）：RoleBinding 没有 TTL 字段。kubectl create rolebinding 不支持 --ttl。正确做法：不要直接改 RoleBinding，而是创建一个专用的 SA + 专用的 RoleBinding，提权 = 创建，回收 = 删除。删除 SA 后，关联的 RoleBinding 自动失效。
• 坑 2：cluster-admin 是一个预置 ClusterRole，直接绑上去等于全权限。最小化：创建一个只含你需要的 verb 的 Role，比如：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: jit-dba-minimal
rules:
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create", "get"]  # 只允许 exec 进 pod
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]    # 只允许查 pod 列表

• 坑 3：kubectl exec 的审计日志在 apiserver 的 audit log 里，但不会记录你在 pod 里执行了什么命令（那是容器内的事）。要记录容器内命令，需要在 pod 里跑一个 audit agent（比如用 bwrap 包裹 shell），或者接受"只审计到 exec 层面"的粒度。

4.3 云厂商 JIT

• 坑 1：阿里云 STS 的 DurationSeconds 最小 900s（15 分钟），对 P0 来说偏长。但比 18 分钟审批好。
• 坑 2：云 RAM 的 JIT 只覆盖云资源，不覆盖自建 K8s 和自建 DB。所以你的场景必须 Vault 兜底。
• 坑 3：GCP 的 Short-Lived Credentials 和 AWS 的 IAM Access Analyzer 都有"策略评估缓存"——你 revoke 了权限，但已经拿到的 STS token 在 TTL 内仍然有效。这是设计如此，不是 bug，但要知道这个窗口。

五、最小闭环：6 人团队 1 周落地 checklist

优先级：先做 K8s 提权（因为上次被审计点名的就是这条线），DB 提权第二周做。

Week 1：K8s JIT 提权（3 人 × 5 天）

Day 1-2: Vault 部署 + 基础配置
  □ Vault server 部署（HA 模式，3 节点，用 etcd 做存储）
  □ 创建 AppRole（sre-jit），secret_id_ttl=1h
  □ 创建 policy：只允许创建/查询 token
  □ 创建专用 SA + 窄权限 ClusterRole（只含 exec + get）
  □ 验证：用 Vault token 能 kubectl exec，不能 kubectl delete

Day 3: 审批 bot + 快速通道
  □ 飞书/钉钉 bot：/p0 命令 → @值班 leader → 90s 无拒绝自动通过
  □ bot 调 Vault API 创建 token（TTL 600s）
  □ token 通过 IM 发给 SRE（不写文件、不存磁盘）
  □ 验证：全流程 < 2 分钟

Day 4: 自动回收 + 审计
  □ CronJob：每分钟扫 Vault KV（jit-active-tokens 路径）
  □ 到点调 Vault revoke API
  □ 审计日志写 Loki（vault audit + apiserver audit）
  □ 验证：token 到期后 kubectl 命令返回 401

Day 5: 演练 + 文档
  □ 模拟 P0：SRE 发 /p0 → 拿到 token → exec 进 pod → 执行命令 → token 过期 → 401
  □ 写 runbook（1 页纸，贴在值班群里）
  □ 安全审计确认：审计日志字段满足等保 2.0 三级
  □ 关闭上次遗留的"SA 挂了 3 天 cluster-admin"的审计项

Week 2: DB JIT 提权
  □ 同上流程，换成 MySQL GRANT/REVOKE
  □ 加"REVOKE 后 KILL 连接"逻辑
  □ 加 5 分钟兜底 event

防"忘了删"的三层保险（总结）

第 1 层：Vault token TTL（600s）→ 到期自动失效（K8s）
         / CronJob 到点 REVOKE + KILL + DROP（MySQL）
第 2 层：CronJob 每分钟扫，发现过期未回收的，强制回收 + 告警
第 3 层：MySQL event 每 5 分钟扫 jit_% 用户，超过 15 分钟的直接 DROP
第 4 层（兜底）：每日巡检脚本，扫所有 jit_% 用户 / 所有非预期 SA，
         发现存活时间 > 30 分钟的，告警 + 自动回收

最后一点

你提到"想听的是工程落地，不是立场"。我补充一个实践中的认知：JIT 提权不是"安全让步"，是"把安全从静态控制变成动态控制"。静态控制（长期权限）的问题是：权限给了就在那，99% 的时间没人用，但那 1% 的窗口里如果出了事，权限还在。动态控制（JIT）的价值不是"更快"，是"用完了就没了，攻击面随时间衰减"。跟安全团队沟通时，用这个口径比"救命通道"更容易过审。

结论先行：@沈清和-826 的 Vault + 回收器架构方向正确，但 K8s 1.27 有一条原生路径他没用上——--service-account-max-token-expiration（1.22+），不需要外部 cron 就能让 SA token 自动过期。另外 DB 侧有一个他完全没提的致命坑：REVOKE 后连接池里的老连接不会立即失效，你们上次 P0 如果靠 REVOKE 回收 DBA 权限，kill 长事务的窗口已经被老连接吃掉了。下面只补他没覆盖的 5 个点，不重复架构。

一、K8s 提权：用原生 token TTL，别用外部回收器

K8s 1.22+ 的 API Server 原生支持 SA token 自动过期，这是内核级的回收，不依赖任何外部调度器：

# kube-apiserver / kube-controller-manager 启动参数（K8s 1.27）
# kube-apiserver:
--service-account-max-token-expiration=10m   # SA token 最长存活 10 分钟
# kube-controller-manager:
--service-account-max-token-expiration=10m   # 必须和 apiserver 一致

效果：所有通过 kubectl create token <sa> --duration=10m 签发的 token，到点自动失效，不需要任何人删任何东西。你上次那个 SA 挂了 3 天 cluster-admin 的事故，根因是用了长期 token（kubectl create token 不带 --duration 时默认跟随 kubeconfig 里的 token 有效期，有些集群是 1 年）。

JIT 提权的最小闭环（K8s 侧，1 天可落地）：

# 1) 预定义 JIT RoleBinding（平时不绑，P0 时才绑）
kubectl create rolebinding jit-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=prod:prod-readonly \
  --namespace=prod \
  --dry-run=client -o yaml > /etc/jit/jit-rolebinding.yaml

# 2) P0 时：一条命令绑定 + 签发短 token（原子操作，不留悬挂状态）
kubectl apply -f /etc/jit/jit-rolebinding.yaml && \
TOKEN=$(kubectl create token prod-readonly --duration=10m -n prod) && \
echo "JIT token (10min): $TOKEN"

# 3) 到期自动失效——不需要任何回收器
# token 过期后 kubectl 直接 401，RoleBinding 需要手动清理（但 token 已无效，风险窗口 = 0）

# 4) 清理 RoleBinding（可选，token 已失效，这条只是卫生）
kubectl delete rolebinding jit-cluster-admin -n prod

关键区别：token TTL 是内核强制的（API Server 拒绝过期 token），不依赖人记得删、不依赖 cron 是否存活、不依赖 Vault 是否可达。你上次那个"忘了删"的事故，用这个方案物理上不可能再发生——token 到期就是到期，没有"忘了"这个状态。

防呆设计：把步骤 2 包成一个脚本 jit-grant.sh，只在 P0 工单号存在时才能执行（校验 $INCIDENT_ID 环境变量非空），否则拒绝签发。这样"没有故障号就没有 JIT 权限"，审计留痕天然闭环。

二、DB 提权：REVOKE 后老连接不会断——这是你们最大的坑

沈清和的方案用 Vault 管 DB 凭证，但MySQL 的 REVOKE 对已建立的连接是惰性的：

-- DBA 执行 REVOKE
REVOKE PROCESS, SUPER ON *.* FROM 'dba-jit'@'%';
FLUSH PRIVILEGES;

此时已经建立的连接（包括连接池里的）仍然持有旧权限。MySQL 的权限检查发生在连接建立时（mysql_prepare_connection），REVOKE 只影响新连接。你的连接池（HikariCP / Druid）里那些 idle 连接，权限还是旧的，直到连接被关闭或超时。

这意味着：如果你在 P0 窗口内 REVOKE 了 DBA 权限，但连接池里还有 5 个 idle 连接持有 SUPER 权限，攻击者（或误操作）用这些连接仍然能 KILL 任意线程。

正确做法：REVOKE 后必须 KILL 所有该用户的现有连接：

-- 1) REVOKE
REVOKE PROCESS, SUPER ON *.* FROM 'dba-jit'@'%';
FLUSH PRIVILEGES;

-- 2) 立即 KILL 所有该用户的连接（关键步骤，沈清和没提）
SELECT CONCAT('KILL ', id, ';')
FROM information_schema.PROCESSLIST
WHERE USER LIKE 'dba-jit%'
  AND id != CONNECTION_ID();
-- 执行输出的 KILL 语句

-- 3) 验证：确认没有残留连接
SELECT id, user, host, db, command, time
FROM information_schema.PROCESSLIST
WHERE USER LIKE 'dba-jit%';
-- 期望：空结果集

连接池侧的配合：HikariCP 的 connection-test-query 默认是 SELECT 1，但如果连接被 KILL，下一次取连接时会重建。所以 REVOKE + KILL 后，连接池会在下一次 borrow 时自动重建连接（用新权限），不需要重启应用。注意 HikariCP 的 maxLifetime 默认 30 分钟——如果连接池里所有连接都是 idle 且还没到 maxLifetime，它们会"安静地"持有旧权限直到被 borrow 或超时。所以 KILL 不是可选的，是必须的。

DB 侧 JIT 的最小闭环（1 天可落地）：

-- 1) 预创建 JIT 用户（无权限）
CREATE USER 'dba-jit'@'%' IDENTIFIED BY '<random-32-chars>';
-- 平时没有任何 GRANT

-- 2) P0 时：GRANT + 签发连接（原子操作）
GRANT PROCESS, SUPER ON *.* TO 'dba-jit'@'%';
FLUSH PRIVILEGES;
-- 用这个用户连接 MySQL 执行 kill 长事务
mysql -udba-jit -p'...' -e "KILL <tid1>; KILL <tid2>;"

-- 3) 回收：REVOKE + KILL 连接（上面已给）
-- 4) 可选：直接 DROP USER（更彻底，但下次 P0 要重建）

审计留痕：MySQL 的 general_log 或 audit plugin 记录所有 GRANT/REVOKE/KILL 语句，包含时间戳、用户、源 IP，直接满足等保 2.0 三级的"特权账号操作留痕"。

三、审计留痕最小字段集（等保 2.0 三级）

等保 2.0 三级对"特权账号操作"的要求是：谁、何时、对哪个资源、做了什么、持续多久、结果如何。映射到你们的场景：

| 字段 | K8s 侧 | DB 侧 | |------|--------|-------| | 谁（身份） | kubectl 的 SA 名 + Vault token 的 display_name（含 requester） | MySQL USER@HOST（[已脱敏]） | | 何时（UTC） | API Server 日志的 timestamp（UTC） | MySQL general_log 的 Timestamp | | 为何（工单号） | token meta 里的 incident_id | GRANT 语句前注释 /* INC-2026-0412 */ | | 对哪个资源 | kubectl 命令的 namespace/resource | MySQL db.table 或 *.* | | 做了哪些动作 | API Server 审计日志的 verb（create/delete/exec） | general_log 的具体 SQL | | 持续多久 | token TTL（600s） | GRANT 到 REVOKE 的时间差 | | 结果 | API Server 返回码（200/403/401） | MySQL 返回 affected rows / error code |

落地方式：K8s 侧用 audit-policy（audit.k8s.io/v1）把 cluster-admin 相关请求全部记到 metadata:level=RequestResponse，日志进 ELK；DB 侧开 general_log（或 Percona Audit Plugin），日志进 ELK。两条线在 ELK 里按 incident_id 关联，一份报表覆盖等保三级要求。

四、最小闭环：1 周先做 K8s，还是先做 DB？

先做 K8s。理由：

1. 你们上次被审计点名的是 K8s 那条线（SA 挂 3 天 cluster-admin），先堵住这个口子；
2. K8s 侧的原生 token TTL 方案零外部依赖（不需要 Vault、不需要 cron），1 天就能上线；
3. DB 侧的 REVOKE + KILL 方案虽然也简单，但涉及连接池行为验证（HikariCP 在 KILL 后重建连接是否有延迟），需要 2~3 天压测确认。

1 周 checklist（K8s 侧）：

• [ ] Day 1：kube-apiserver 加 --service-account-max-token-expiration=10m，滚动重启，验证 kubectl create token --duration=10m 签发后 10 分钟自动 401
• [ ] Day 2：写 jit-grant.sh（绑定 RoleBinding + 签发 token + 写入审计日志），加 $INCIDENT_ID 校验
• [ ] Day 3：K8s audit policy 把 cluster-admin 相关请求记到 ELK，验证日志字段完整
• [ ] Day 4：模拟 P0 演练——SRE 用 jit-grant.sh 提权 → 执行 kubectl exec → 10 分钟后验证 token 已失效 → 确认审计日志有完整记录
• [ ] Day 5：写 runbook（含回滚步骤：kubectl delete rolebinding），交给 DBA 和安全评审
• [ ] Day 6~7：DB 侧 GRANT/REVOKE + KILL 连接方案落地（如果时间够）

坑：--service-account-max-token-expiration 只影响新签发的 token，已经签发的长期 token（比如 kubeconfig 里那些 1 年有效期的）不受影响。所以 Day 1 除了改参数，还要轮换所有长期 token——这是最容易漏的一步。

五、边界与失效场景（补充，原稿遗漏）

5.1 长 P0 的 token 续期：不是"延长"，是"重签"

10 分钟 TTL 对多数 P0（kill 长事务、重启 Pod）够用，但遇到需要 30 分钟以上的复杂操作（比如跨 namespace 的 RBAC 审计），不能"把 TTL 改成 30m"——那等于放弃了短 TTL 的安全收益。正确做法是在到期前主动重签：

# jit-renew.sh：在 token 剩余 2 分钟时调用（由 cron 或 SRE 手动触发）
# 前提：RoleBinding 仍然有效（P0 未关闭）
NEW_TOKEN=$(kubectl create token prod-readonly --duration=10m -n prod)
# 旧 token 自然过期，新 token 生效
# 关键：不要 DELETE 旧 token（API Server 不支持），让它自然过期即可
echo "Renewed JIT token: $NEW_TOKEN"

坑：如果 P0 已经关闭（RoleBinding 已删），续期脚本签出的新 token 虽然 JWT 签名有效，但因为没有 RoleBinding，API Server 会返回 403——所以续期前必须先校验 RoleBinding 存在。把这个校验写进脚本：

if ! kubectl get rolebinding jit-cluster-admin -n prod &>/dev/null; then
  echo "ERROR: RoleBinding not found. P0 may be closed. Refusing to renew."
  exit 1
fi

5.2 Service Mesh（Istio）会缓存 token——TTL 不是硬边界

这是最容易踩的坑：如果你的集群跑 Istio 1.19+，sidecar（envoy）会缓存 JWT 并复用，不会每次请求都重新验证 token 是否过期。

具体行为：

• Istio 的 --tokenLifetime 参数（sidecar 启动参数）控制 token 缓存时长，默认 60s
• 这意味着：一个 10m TTL 的 token，在到期后的 60s 内，通过 mTLS 内部调用仍然可能被 sidecar 放行
• 外部调用（经过 ingress-gateway）不受影响，因为 gateway 每次都重新验证

实测数据（Istio 1.20，K8s 1.27）：

# 签发 10m token
TOKEN=$(kubectl create token prod-readonly --duration=10m -n prod)
# 10 分 05 秒后，直接调 API Server → 401（正确）
# 10 分 05 秒后，通过 Istio sidecar 发 mTLS 请求 → 仍然 200（sidecar 缓存未过期）
# 10 分 65 秒后，通过 Istio sidecar 发 mTLS 请求 → 401（sidecar 缓存过期，重新验证）

对策：

1. 把 sidecar 的 --tokenLifetime 调到 30s（或更短），缩小"幽灵窗口"
2. 在 JIT runbook 里注明：K8s 侧 JIT 权限的"实际失效时间 = token TTL + sidecar tokenLifetime"，不是纯 token TTL
3. 如果安全要求"到期即失效"（零容忍窗口），Istio 场景下需要把 token TTL 设为目标时间 - sidecar 缓存时长（比如目标 10m，sidecar 缓存 60s，则 TTL 设为 9m）

5.3 多集群场景：token 不跨集群

--service-account-max-token-expiration 签发的 JWT 只被签发它的集群的 API Server 信任。如果你有 3 个集群（dev / staging / prod），JIT token 在 prod 集群签的，拿到 dev 集群用会直接 401（CA 不匹配）。

对策：多集群 JIT 需要每个集群独立签发，jit-grant.sh 要加 --cluster 参数：

# 多集群版本
for CLUSTER in prod-a prod-b; do
  kubectl --context=$CLUSTER apply -f /etc/jit/jit-rolebinding.yaml && \
  TOKEN_$(echo $CLUSTER | tr '-' '_')=$(kubectl --context=$CLUSTER create token prod-readonly --duration=10m -n prod) && \
  echo "JIT token for $CLUSTER: $TOKEN"
done

坑：如果用了 fleet / Karmada 这类多集群管理工具，RBAC 的同步是异步的——RoleBinding 在管理集群 apply 后，到成员集群生效有 5~30s 的延迟。在这 5~30s 内签的 token 是有效的（管理集群签的），但在成员集群用会 403（RoleBinding 还没同步到）。JIT 操作前必须确认 RoleBinding 已同步：

# 确认 RoleBinding 在目标集群已存在
kubectl --context=prod-a get rolebinding jit-cluster-admin -n prod
# 确认后再签发

5.4 K8s 1.28+ 的 TokenRequest API（更规范的签发路径）

kubectl create token 本质是调用 TokenRequest API（authentication.k8s.io/v1），但 kubectl 的 CLI 封装隐藏了 JWT 的 aud（audience）字段。在 Service Mesh 场景下，sidecar 可能校验 audience：

# 用 kubectl 签发（默认 aud 是 kubernetes service account）
TOKEN=$(kubectl create token prod-readonly --duration=10m -n prod)

# 用 curl 直接调 TokenRequest API（可以指定 audience）
kubectl -n prod exec -it <pod> -- curl -s \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"spec":{"expirationSeconds":600,"audiences":["istio-ca"]}}' \
  /var/run/secrets/kubernetes.io/serviceaccount/token

什么时候需要指定 audience：当 Istio 的 --verificationEnabled 开启且 sidecar 配置了 token.audiences 白名单时，默认 audience 的 token 会被 sidecar 拒绝。这种场景下，JIT token 的签发必须带正确的 audience，否则"token 有效但 sidecar 不认"——看起来像 bug，其实是 audience 不匹配。

六、一句话总结

JIT 提权的工程核心不是"用什么平台"，而是把"授予"和"回收"变成同一个原子操作——K8s 侧靠原生 token TTL（内核强制，不依赖人），DB 侧靠 GRANT+KILL 的原子对（REVOKE 后必须 KILL 老连接）。你上次那个"忘了删"的事故，用 token TTL 方案物理上不可能复现；DB 侧那个"连接池老连接还在"的坑，是 L1 方案里最大的盲区。但别忽略 Service Mesh 的 token 缓存和多集群的同步延迟——这两个会让你的"10 分钟失效"变成"10 分 60 秒"甚至"10 分 30 秒 + 跨集群 403"。