构建K8s紧急排障权限的回收机制

凌晨两点，我 kubectl debug 进一个 CrashLoopBackOff 的 Pod，两分钟后定位到问题。第二天中午我突然想起来，那个临时容器还在——shell 早退了，进程可能还挂着，Pod 挂载的 Secret 它照样能读。这事让我意识到，紧急排障的权限治理里最难的不是“怎么给”，而是“怎么收”。

临时容器不会自己消失

这是最容易被忽略的一点。调试会话结束、shell 退出，临时容器并不会被删除，它仍然留在 Pod 的 ephemeralContainers 列表里，直到 Pod 本身被删掉。也就是说，一次本该结束的调试，实际上留下了一个持续持有挂载卷和网络命名空间的容器。

我的做法是把它当成交接动作：调试结束必须清理。要么删除 Pod（代价是会重建，滚动更新状态受影响），要么用 patch 把 ephemeralContainers 置空，但这需要 pods/ephemeralcontainers 的 patch 权限。指望人靠记性完成这一步，迟早会漏，所以我们加了一个定时扫描任务，超过阈值还没清掉的直接告警。原文里提的经验值是三十分钟，实际定多少看自己团队的响应节奏。

权限那头更难收

比残留容器更麻烦的是权限绑定本身。排障权限往往是临时的，可 RoleBinding 建完就没人管了。我见过半年前为一次事故开的绑定，一直安静地躺在命名空间里。

现在我们会给这类绑定打上过期时间注解，用定时任务检查到期就删。删完不算完，还得验证——kubectl auth can-i create pods/ephemeralcontainers --as=<user> -n <namespace> 返回 no，才算真的收回来了。这一步我强烈建议塞进流水线或定期扫描脚本，因为权限这东西，回退得悄无声息。

回滚也得提前想好

收权限一定会影响排障能力，所以变更前我习惯先把 YAML 版本化存好。准入策略先跑 Audit 模式观察一阵，确认没误伤合法排障再切 Enforce；真出问题，改回 Audit 或删掉策略对象就能恢复。审计策略的变更要重启 kube-apiserver 才生效，这个窗口对控制面的影响得提前评估，别在业务高峰动手。

我现在看临时容器，不太把它当一条普通运维命令，更像是需要登记和注销的特权通道。给的时候痛快，收的时候较真，排障效率反而更稳——因为你知道下一次还能用，而不是某天发现权限被一刀切没了。