已采纳
回答正文
回复
讨论正文
该问题的正文与回答。
背景
我负责一套 K8s 1.28.9(containerd 1.7.13,cgroup v2,内核 5.15,约 50 节点)的容器安全加固。业务侧 40+ 微服务,数据库密码、SASL 凭据、第三方 API Key 全部走 K8s Secret + volume 注入(secretMounts,容器内挂载路径如 /etc/secrets/,readOnly: true)。社区里讨论过 Secret 放 etcd 的爆炸半径问题(温望舒那篇),也讨论过红队用 DNS 侧信道把 Secret 外泄出去的路径(温砚舟-409 那篇),但有一个我认为最容易被忽略的落盘点没人系统拆过:kubelet 把 Secret 写进容器文件系统时,在节点侧留下了什么。
现象 / 我实测到的
昨天在一个节点上做了个对照实验:
secretMounts 的 Pod(secret 里放一个 32 字节随机串 DEADBEEF...);grep -r DEADBEEF /var/lib/containerd/... 能命中(overlay upperdir 里有明文);kubectl delete pod 之后,在 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/*/fs/ 下用 grep -rl DEADBEEF 依然能命中——Pod 已经没了,明文文件还在节点磁盘上;/var/lib/kubelet/pods/<uid>/volumes/kubernetes.io~secret/<name>/(syncSecretsToPodDir),再 bind mount 进容器;容器 rootfs 是 overlay,只读挂载进容器的文件在写操作时会 COW 到 upperdir——而 kubelet 的 sync 过程本身可能就会触发 COW(取决于 mount flags)。已尝试的排查
crictl inspect 的 mount 列表,确认 secret 路径是 bind,rw 还是 bind,ro(不同版本行为不一致);lsof / fuser 在节点上确认哪些进程持有这些文件(结果只有 kubelet 和容器内进程);inotifywait 监听 /var/lib/kubelet/pods/ 和 overlayfs snapshots 目录,能抓到写入事件,但没有现成的告警规则告诉我「哪个文件是 secret 残留」。期望得到的答案形态
readOnly: true 到底能不能阻止 COW 到 upperdir?);auditctl -w ... -p wa),告警阈值怎么定;emptyDir.medium: Memory + 一个 init container 从 API 拉下来),能完全避免节点磁盘落盘吗?代价是什么(节点重启丢失、内存占用、多副本一致性)?引用依据: