随着越来越多的业务系统以容器方式运行在Kubernetes（K8s）之上，等保合规的检查对象也从传统物理机和虚拟机，延伸到集群内的日志、权限与网络安全三个层面。与传统架构不同，K8s的控制平面、工作节点、镜像仓库、服务网格与CI/CD流水线共同构成一个动态边界，整改工作需要在集群内部逐项梳理、逐项落地。本文以运维实践为线索，梳理一次云原生K8s等保整改的推进思路，供正在做合规建设的团队参考。

一、先梳理范围：明确等保对象与K8s资源边界

整改的第一步不是改配置，而是确定“改什么”。等保测评关注的是承载业务的信息系统，因此需要先把集群中承载业务的命名空间、工作负载、对外暴露的服务梳理清楚，形成资产清单。

• 控制平面资产：API Server、etcd、Scheduler、Controller Manager所在节点及其管理入口。
• 工作节点资产：kubelet、容器运行时、节点操作系统及内核参数。
• 业务资产：Deployment、StatefulSet、Service、Ingress、ConfigMap、Secret等对象的归属与责任人。
• 周边资产：镜像仓库、制品库、日志与监控平台、CI/CD系统、堡垒机与VPN入口。

资产清单与等保测评项对应起来，才能判断哪些要求已在原生层面满足、哪些需要额外组件补足。这一阶段的输出通常是一份“资产—责任—整改项”对照表，后续所有工作都围绕它推进。

二、日志审计：从“有日志”到“可追溯”

等保对安全审计的要求集中在留存时间、内容完整性、防止未授权删除与审计记录可查询。容器环境的难点在于日志分散、生命周期短、Pod重建后本地日志随之消失。

2.1 日志采集范围

• K8s审计日志：在API Server开启审计策略，记录谁在什么时候对哪些资源执行了什么操作，是集群层最重要的审计来源。
• 组件日志：kubelet、etcd、容器运行时、Ingress控制器的运行日志。
• 应用日志：容器标准输出与业务日志文件，通过DaemonSet或Sidecar方式采集。
• 操作日志：节点登录、堡垒机会话、镜像推送、CI/CD发布记录。

2.2 采集与留存建议

1. 统一采集到集中式日志平台，避免日志仅存在于节点本地。
2. 为不同来源设置不同的索引与保留策略，满足等保对留存时间的要求。
3. 日志传输采用加密通道，写入端与查询端分离权限。
4. 对日志存储设置写一次读多次或等效保护，防止被篡改和删除。
5. 配置关键事件的告警规则，例如高权限操作、异常登录、审计配置变更。

需要强调的是，日志“全项达标”不仅指采集齐全，还包括时间同步。集群节点、控制平面与日志平台应统一使用可靠的时间源，否则审计记录的时间线无法串联。

三、权限治理：最小权限与职责分离

K8s的RBAC模型本身提供了较细的授权能力，问题往往出在长期积累的宽松配置上，例如默认使用cluster-admin、ServiceAccount权限过大、长期有效的静态Token等。

3.1 账号与身份梳理

• 区分人与机器身份：人员通过统一身份源接入，机器使用独立ServiceAccount。
• 对集群管理入口启用多因素认证，并限制来源地址。
• 清理离职、转岗人员残留的证书、Token与kubeconfig文件。

3.2 RBAC收敛

1. 盘点ClusterRoleBinding与RoleBinding，识别绑定到cluster-admin、edit等高权限角色的主体。
2. 按“命名空间+角色”授权，避免跨命名空间的隐式越权。
3. 对ServiceAccount按需授权，关闭默认自动挂载Token，除非工作负载确实需要访问API。
4. 建立角色申请与审批流程，保留授权变更记录。

3.3 密钥与凭据管理

• Secret中的敏感数据应结合外部密钥管理或集群内加密存储方案，避免以明文形式落入etcd。
• 避免在镜像、ConfigMap、代码仓库中长期保存明文口令。
• 凭据定期轮换，并记录轮换责任人。

权限整改的落地要点是可审计：每一次授权变更都要有申请、审批、执行、复核的闭环记录，才能在测评中说明管理措施的有效性。

四、网络安全：东西向与南北向同时收敛

容器网络的默认行为是Pod之间可互访，这与等保对访问控制、边界防护和入侵防范的要求存在差距。整改需要同时覆盖南北向（集群外到集群内）和东西向（Pod与Pod之间）流量。

4.1 边界与入口

• 明确对外暴露的Service与Ingress清单，非必要不暴露。
• 入口统一接入WAF或等效防护，启用TLS并配置合理的加密套件。
• 管理入口（API Server、Dashboard、监控面板）与业务入口分离，管理入口限制访问来源。

4.2 集群内东西向控制

1. 启用NetworkPolicy，默认拒绝，按业务调用关系逐条放行。
2. 按命名空间划分安全域，例如生产、预发、测试相互隔离。
3. 对数据库、中间件等关键服务仅允许指定工作负载访问。
4. 定期核查策略与实际调用关系的偏差，清理历史遗留的宽泛规则。

4.3 主机与节点安全

• 节点操作系统按基线加固，关闭无用端口与服务。
• 容器运行时遵循最小权限，禁止特权容器，限制hostPath、hostNetwork等高风险配置。
• 镜像来源可信，启用镜像扫描，阻断高危漏洞镜像进入生产。
• 开启运行时检测，对异常进程、异常外联行为进行告警。

五、整改落地节奏与常见问题

上述四类工作并非彼此独立，日志采集依赖权限规划，网络策略调整会影响业务连通性，因此建议按阶段推进：

1. 梳理阶段：完成资产、权限、暴露面与日志现状盘点，形成差距清单。
2. 试点阶段：选择一到两个非核心命名空间，验证审计日志、RBAC收敛与NetworkPolicy的效果。
3. 推广阶段：分批推进，每次变更前准备回滚方案，变更后观察业务指标。
4. 固化阶段：将策略写入CI/CD与准入控制，使新上线工作负载自动符合基线。
5. 复核阶段：形成自查报告，配合测评机构完成整改验证。

常见问题提示

• 审计日志开启后存储增长过快：应提前评估容量与保留周期，按敏感级别分级记录，而非一律记录全量请求体。
• NetworkPolicy启用后业务不通：先以“只记录不阻断”的方式观察流量，再逐步切换为拒绝。
• 权限收敛引发发布中断：CI/CD使用的ServiceAccount权限应单独梳理，避免与人员权限混用。
• 整改后配置回退：把关键策略纳入版本控制和准入校验，防止手工修改被覆盖或遗忘。

六、小结

云原生环境下的等保整改，核心不是引入某个单一产品，而是围绕日志可追溯、权限最小化、网络可控制三条主线，把K8s原生能力与安全组件组合成可持续运行的机制。整改完成的标准不只是测评通过，更在于策略被固化进日常发布流程，使新业务上线即符合基线，避免整改成果随时间衰减。对于正在推进此项工作的团队，建议从资产梳理入手，小范围试点验证，再分批推广并保留完整的变更记录，这样既能控制风险，也能为后续复核提供充分依据。