K8s安全怎么做？镜像、网络、权限与运行时防护

K8s安全要从镜像供应链、权限控制、网络隔离、配置密钥、准入策略、运行时防护和审计追踪多个层面协同建设。Kubernetes 提供了安全机制，但默认配置并不等于生产安全，企业需要把这些机制纳入统一治理流程。

K8s安全为什么是体系工程

Kubernetes 集群中有很多对象和入口：镜像仓库、API Server、节点、Pod、Service、Ingress、Secret、CI/CD 流水线。任何一环配置不当，都可能扩大风险。

典型风险包括：

• 使用存在漏洞的基础镜像
• 业务容器以高权限运行
• 所有团队共享管理员账号
• Pod 之间默认互通缺少限制
• Secret 权限过宽
• 生产变更缺少审计
• 运行时异常行为无法发现

K8s安全能力分层

镜像安全怎么做

镜像是应用进入集群的入口。企业应建立镜像仓库、扫描、签名和准入流程。不要让生产集群随意拉取未知来源镜像，也不要把敏感配置写入镜像。

建议做到：

• 使用可信基础镜像
• 构建阶段进行漏洞扫描
• 镜像版本可追溯
• 禁止生产使用 latest 标签
• 高危漏洞镜像禁止发布

权限和网络怎么控制

RBAC 应按最小权限设计，普通研发和流水线账号不应拥有集群管理员权限。命名空间、Role、RoleBinding、ServiceAccount 要按团队和环境拆分。

网络层面，生产环境应使用 NetworkPolicy 控制服务访问边界，入口流量统一通过 Ingress、网关或负载均衡。

运行时防护关注什么

镜像上线后仍可能出现异常行为，例如容器内执行可疑命令、访问异常外部地址、尝试提权、扫描内网或读取敏感文件。运行时安全要关注行为监控、异常告警和应急处置。

同时要限制容器能力：避免特权容器、限制宿主机挂载、控制 root 用户、限制危险 Linux capabilities。

企业落地步骤

1. 梳理集群、命名空间和业务等级。
2. 建立镜像仓库和扫描准入流程。
3. 按团队和环境重构 RBAC。
4. 对生产命名空间启用网络策略。
5. 规范 Secret 和配置管理。
6. 开启审计日志和关键操作告警。
7. 接入运行时安全和应急流程。

常见误区

只做镜像扫描就算安全

镜像扫描只是入口，权限、网络、运行时和审计同样重要。

内网集群就不需要安全策略

很多安全事件发生在内网横向移动。内网不代表可信。

为了方便给流水线管理员权限

CI/CD 账号权限过高非常危险，应只授予发布所需的最小权限。

K8s安全治理要形成闭环

K8s安全不是把镜像扫描、RBAC、NetworkPolicy 分别配置一遍就完成。企业需要形成从构建、发布、准入、运行到审计的闭环：镜像进入仓库前扫描，进入集群前校验策略，运行时持续监控异常，事后能通过日志和审计还原事件。

一个完整闭环通常包括：

• 构建前移：依赖扫描、密钥扫描和基础镜像治理。
• 制品可信：镜像签名、版本追溯和仓库权限管理。
• 准入控制：禁止高危配置进入生产集群。
• 运行时防护：发现异常进程、网络连接、提权和敏感文件访问。
• 审计复盘：记录权限变更、发布操作和敏感资源访问。

K8s安全的关键不是单个工具能力，而是安全策略是否嵌入日常交付和运维流程。

最容易被忽略的风险点

很多生产集群的风险来自默认配置：默认 ServiceAccount 被过度使用，命名空间之间默认互通，Secret 未加密或权限过宽，CI/CD 凭据权限过大，测试镜像进入生产。这些问题单独看不一定立刻出事故，但叠加后会显著扩大攻击面。

建议把高权限账号、特权容器、hostPath、latest 镜像、NodePort 暴露和生产无审计列为重点检查项。

结语

K8s安全不是单点工具，而是一套覆盖供应链、权限、网络、密钥、准入、运行时和审计的治理体系。企业应把安全策略嵌入平台和发布流程，而不是等故障后再补救。

FAQ

K8s默认安全吗？

Kubernetes 提供安全机制，但默认配置未必满足企业生产要求。需要根据业务和合规要求加固。

NetworkPolicy一定要开启吗？

生产多租户场景建议开启。它可以限制 Pod 之间的访问关系，减少横向移动风险。

Secret是不是绝对安全？

不是。Secret 需要配合 RBAC、加密、审计和密钥轮换使用，不能因为用了 Secret 就放松权限控制。

K8s安全最容易忽略什么？

最容易忽略的是 ServiceAccount 权限、审计日志、运行时异常行为和镜像来源治理。