已采纳
回答正文
回复
讨论正文
该问题的正文与回答。
背景
我负责一套约 120 个微服务(Java/Go 混合,K8s 1.27 自建集群)的安全加固。过去半年把一批"长期高权限账号"往最小权限收敛:cluster-admin SA 拆成 per-service 的窄 RoleBinding、DBA 超级账号拆成 per-schema、云 RAM 的 * 权限收成 read-only + 显式写白名单。方向大家认可,但运维和 DBA 反复提同一个抱怨:"出事时救不了急。" 上个月一次 P0(支付链路 5xx 飙升),DBA 想 kill 一批长事务,走审批 18 分钟,黄金 5 分钟窗口已经烧掉,最后是靠 SRE 手动登到 pod 里用 root 执行的——事后安全审计直接点名。
这个矛盾在社区讨论层面其实已经聊过几轮:#416 的"应急调试后门谁让步"、#555 的"救命通道"、#925 的"智能体最小权限",但都停在该不该保留的立场之争,没看到把"临时提权"做成一条工程化流水线的可复现方案。所以想问具体的落地。
现象与卡点 我们现在的两难:
已尝试(都卡在半路)
prod-readonly SA 绑到 cluster-admin,秒级生效,但没有自动回收——上次一次故障后忘了删 RoleBinding,那个 SA 在 cluster-admin 状态下挂了 3 天才被巡检发现,直接被安全审计点名;sudo -E -g -t 300 能限时,但只对 shell 有效,对 DBA 的 DB 权限、对云 API 的 RAM 权限完全不通用,且 sudo 的 TTL 是 per-TTY,跨会话/跨主机不生效;期望得到的答案形态(越具体越好,最好带命令 / 配置 / 时间线)
expire_at、DB 的 SET SESSION 级权限、还是外部调度器到点回收?怎么防"忘了删"?有没有踩过"过期了但连接池里老连接还在"的坑?token_policies + 审批 policy、云厂商 JIT(AWS IAM Access Analyzer / GCP Short-Lived Credentials / 阿里云 STS),各自踩过什么坑?约束
相关讨论(已读过,作为背景)
想听的是工程落地,不是立场。