K8s安全：管好编排平台的命门
导语：Kubernetes管着成百上千容器，一旦控制面失守，等于把整个集群钥匙交出去。K8s安全是云原生安全的"总阀门"。
一、为什么要关注
K8s已成为政企容器编排事实标准，但其默认配置偏便利而非安全：API Server暴露、匿名访问、过宽RBAC、敏感Secret明文，都可能被利用提权至集群管理员。等保2.0对集中管控有要求，密评GB/T 39786关注重要系统的访问控制。K8s安全把防护做在控制面、认证、网络与供应链四道关口。
二、核心原理
K8s安全四关：认证授权（API Server强鉴权、RBAC最小权限、禁匿名）；控制面加固（API Server不暴露公网、etcd加密）；网络策略（默认拒绝东西向，见91）；Secret与供应链（Secret加密、镜像可信）。核心是"最小权限+默认拒绝"——任何组件只给必需权限，未显式允许即拒绝。
K8s安全的命门在控制面。API Server一旦暴露公网或被匿名访问，等于把集群钥匙交出去；过宽RBAC让普通账号可提权至管理员。防护聚焦四关：API收口与强认证、etcd加密、网络策略默认拒绝、Secret加密管理。把"最小权限+默认拒绝"贯彻到编排层，集群才真正可控。
三、落地做法/步骤
- 收口API：API Server不暴露公网，强认证。
- 细RBAC：按角色最小授权，定期回收。
- etcd加密：静态加密集群敏感数据。
- 网络策略：默认拒绝，显式放行必要通信。
- Secret管理：接外部密钥库，禁明文。
- 合规扫描：用基线工具持续查偏离。
K8s安全要"常态化审计"：用基线扫描工具持续检查RBAC是否过宽、是否有特权容器、Secret是否明文，把偏离及时告警。对控制面组件（API Server、etcd、控制器）单独加固与备份，确保即使某节点失陷，集群信任根不被动摇。K8s的安全水位，决定了其上所有业务的防护下限；它不稳，上层再花哨也徒劳。建议把安全配置纳入变更评审，每次调整都留痕可溯。
对多数政企，K8s安全可先从"默认安全"基线做起：关匿名、收口API、最小RBAC、Secret加密，四件事即挡住绝大多数常见入侵。先把地基打牢，再谈进阶的网格与策略治理，安全能力才能稳步上台阶。
四、与群晖NAS/信创云盘的对应能力
集群配置、Secret备份、合规报告需安全留存。群晖DS1525+、DS1825+可作为etcd快照与备份的集中存储；信创云盘（软件化部署、支持信创）可作为K8s安全基线、RBAC模型的共享空间，按角色授权、全程审计，满足等保2.0对集中管控与密评GB/T 39786对重要系统受控访问的要求。
五、常见误区
- API Server暴露公网，匿名即沦陷。
- RBAC过宽，普通账号可提权。
- Secret明文，密钥随手可得。
六、小结与行动建议
从"API收口+最小RBAC"抓起，集群要可认证、可隔离、可审计。