Kubernetes 安全加固实践：从 RBAC 到运行时防护

Kubernetes 安全不是安装一个扫描工具就结束。它是一套分层防御体系：谁能访问集群、能创建什么资源、镜像是否可信、Pod 以什么权限运行、服务之间能否互通、Secret 如何保存、运行时异常如何发现。任何一层过宽，都会扩大攻击面。

生产集群安全治理的目标不是让所有人都无法操作，而是在不阻塞交付的前提下，把高风险动作变成可控、可审计、可回滚的流程。

身份与 RBAC

RBAC 是 K8s 权限治理的基础。常见问题是直接把用户绑定到 cluster-admin，或者为 CI/CD 系统配置过大的权限。正确做法是按角色、命名空间和动作拆分权限。

原则：

• 人员权限尽量通过组管理。
• 应用 ServiceAccount 只授予所需 namespace 权限。
• CI/CD 权限按部署范围限制。
• 避免给普通应用授予读取所有 Secret 的能力。
• 定期审计 ClusterRoleBinding。

可以用如下命令查看高危绑定：

kubectl get clusterrolebinding -o wide

重点关注绑定到 cluster-admin 的主体，以及长期不用但仍然有效的 ServiceAccount。

准入控制

准入控制可以在资源进入集群前拦截风险配置。常见策略包括禁止特权容器、禁止宿主机网络、限制镜像仓库、要求资源 requests、要求安全上下文、要求标签。

可以使用内置 Pod Security Admission，也可以使用 Kyverno、OPA Gatekeeper 等策略引擎。策略不要一开始就全量强制。建议分阶段：

1. Audit：只记录违规。
2. Warn：给出警告。
3. Enforce：阻断高风险资源。

这样可以避免一次性上线策略导致大量业务发布失败。

Pod 安全上下文

大多数业务容器不需要 root 权限，也不需要特权模式。建议为工作负载设置安全上下文：

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL

如果应用确实需要写文件，应挂载专门的 emptyDir 或 PVC 到指定目录，而不是让整个根文件系统可写。

容器镜像也要配合改造。很多历史镜像默认 root 用户运行，需要在 Dockerfile 中创建非 root 用户并调整目录权限。

镜像供应链

镜像安全包括基础镜像、依赖漏洞、构建过程、签名和拉取来源。生产建议：

• 使用受控镜像仓库。
• 固定镜像 digest，减少 tag 漂移。
• 在 CI 阶段扫描漏洞。
• 对基础镜像建立升级节奏。
• 对生产镜像启用签名验证。

不要把漏洞扫描当成绝对安全。扫描工具依赖漏洞库，也可能误报或漏报。更重要的是建立修复 SLA：高危漏洞多久修，哪些镜像需要优先修。

Secret 管理

K8s Secret 默认是 base64 编码，不是加密。生产环境应启用静态加密，并限制 Secret 读取权限。更成熟的方案是使用外部密钥系统，例如云 KMS、Vault 或 External Secrets Operator。

Secret 管理要避免：

• 把 Secret 写进镜像。
• 把 Secret 提交到 Git。
• 在日志中打印环境变量。
• 给过多 ServiceAccount 授权读取 Secret。
• 长期不轮换数据库密码和 API Token。

对 GitOps 流程，可以使用 sealed-secrets、SOPS 或外部 Secret 引用，避免明文进入仓库。

网络隔离

集群默认全互通会让横向移动变得容易。建议按 namespace 和应用关系建立 NetworkPolicy。至少应做到：

• 默认拒绝生产 namespace 的入站流量。
• 只允许 Ingress/Gateway 访问后端服务。
• 只允许应用访问必要数据库和中间件。
• 限制 Pod 访问云元数据服务。

网络策略上线前要做流量梳理，否则容易误拦截业务。可以先观察日志，再逐步收紧。

节点与控制面

节点安全同样关键。kubelet、容器运行时、宿主机内核、SSH、云安全组都属于攻击面。建议：

• 禁止不必要的 SSH 入口。
• 节点镜像保持补丁更新。
• 限制 kubelet 只接受授权访问。
• 控制节点安全组，只开放必要端口。
• 对系统组件开启审计日志。

控制面托管给云厂商并不意味着不用管安全。你仍然需要管理 API 访问白名单、审计日志、管理员权限和集群版本升级。

运行时监控

准入控制能阻止一部分错误配置，但不能发现所有运行时攻击。运行时监控关注容器启动后发生了什么，例如异常进程、反弹 shell、敏感文件访问、容器逃逸行为、异常网络连接。

可以使用 Falco 或云厂商运行时安全产品。告警规则应结合业务实际，否则噪音很大。比如某些应用本来就会执行 shell 脚本，不能简单一刀切。

审计与追责

开启 Kubernetes Audit Log 可以记录谁在什么时候对什么资源做了什么操作。事故排查时，审计日志能回答很多关键问题：谁删除了 Secret，哪个 CI token 修改了 Deployment，是否有人手动扩容或替换镜像。

审计日志应送入集中日志系统，并设置保留周期。对高风险动作可以建立告警，例如删除 namespace、创建 cluster-admin 绑定、创建特权 Pod。

总结

K8s 安全加固要从入口权限、资源准入、镜像供应链、运行时权限、网络边界、Secret 管理和审计闭环一起做。最好的安全策略不是最复杂的策略，而是团队能持续执行、能在发布流程中自动检查、能在事故时提供证据的策略。安全不是一次整改，而是平台工程的日常纪律。