Kubernetes 安全加固：从 RBAC 到 Pod Security
背景与问题界定 某 SaaS 平台在安全攻防演练中被第三方安全团队成功侵入——攻击者通过一个被攻陷的 CI Runner Pod，利用其绑定的 cluster-admin ServiceAccount 在 2 分钟内创建了后门 DaemonSet，持久化了集群的控制权。事后复盘发现三个致命问题：超过 30 个 ServiceAccount 绑定了 cluster-admin ClusterRole 但实际上只需要 namespace 级别的读写权限；所有 Pod 都以 privileged: true 运行导致容器可以直接访问宿主机内核；没有任何 Admission Controller 对 Pod 的安全性配置进行校验。Kubernetes 的安全模型是典型的"默认准许"模式——默认情况下任何 Pod 都可以做任何事，安全必须通过显式配置来实现。 目标拆解与工程约束 最小权限 RBAC 设计：所有 ServiceAccount 必须遵循"只为完成工作所需的最小权限"原则，彻底消除 cluster-admin 的过度授权，使用 Role/ClusterRole 的细粒度 verbs 控制（get vs list vs watch vs create vs update vs delete）。 Pod 安全合规：所有 Pod 必须遵循 Pod Security Standards（PSS）的 “baseline” 级别以上的安全策略——禁止特权容器、禁止 hostPath 挂载、禁止 hostNetwork、限制 Linux Capabilities。 运行时安全检测：在 Pod 运行时层面通过 RuntimeClass 和 seccomp/AppArmor 限制容器的系统调用能力，结合 Falco 进行异常行为检测，构建运行时安全的"最后一公里"。 密钥管理安全：避免通过 Secret 存储敏感信息导致的 Base64 编码假象（只要具备 etcd 读权限即可解密），集成 External Secrets Operator 或 Vault Provider 实现密钥的外部化管理。 方案设计 RBAC 重构采用"三层角色体系"：平台级（ClusterRole）、Namespace 级（Role）、应用级（ServiceAccount+RoleBinding）。废除了所有非必要的 cluster-admin 绑定，设计了四类标准化角色： ...