K8s安全基线怎么做？4类控制点清单

边界说明：本文给出 K8s 安全基线的通用控制点，不替代企业自身合规评估，也不承诺满足某一具体认证。

K8s 安全基线不是把所有安全工具一次性装上，也不是在上线前临时跑一遍扫描报告。对企业团队来说，更重要的是把身份权限、镜像供应链、运行时防护和审计证据变成可执行、可复查的控制点。

如果安全要求只停留在文档里，平台团队很难判断哪些命名空间可以进入生产、哪些镜像允许部署、哪些运行时风险必须阻断、哪些记录能够支撑审计和复盘。

一、K8s安全基线的目标：先建立可审计控制点

很多企业建设 Kubernetes 安全体系时，会从工具清单开始：镜像扫描、准入控制、日志审计、网络策略、运行时检测都想尽快补齐。工具本身有价值，但如果没有统一基线，结果容易变成各团队各查各的，检查结论也难以复用。

第一类问题是责任边界不清。
平台团队、安全团队、应用团队和运维团队都参与 K8s 安全治理，但每个团队负责什么、哪些项必须在上线前完成、哪些项可以持续优化，如果没有基线约束，很容易在事故或审计时互相补证据。

第二类问题是控制点不可执行。
“加强权限管理”“做好镜像安全”“保留审计日志”这样的表述太宽泛。真正可执行的基线，需要明确检查对象、通过标准、阻断条件和例外审批方式。

第三类问题是证据链缺失。
安全治理不能只依赖口头确认。权限变更、镜像来源、准入结果、运行时告警和复查记录都应能被追溯，否则即使做过检查，也很难证明当时的状态。

因此，K8s 安全基线的目标不是追求一次性完美，而是先形成一组能持续运行的控制点。

二、控制点映射：把安全要求转成检查对象

以下映射图可以作为建立 K8s 安全基线的起点。它把身份权限、镜像供应链、运行时防护和审计证据放在同一张图中，避免安全检查只围绕单个工具展开。

从中可以看出，K8s 安全基线至少要回答 4 个问题：谁能操作、什么能部署、运行时如何发现风险、检查结果如何留下证据。

表格中的 4 类控制点不是彼此独立的清单。权限决定谁能变更资源，镜像供应链决定什么能进入环境，运行时防护决定问题出现后如何发现，审计证据决定治理是否可复查。

三、控制点 1：身份权限和最小授权

身份权限是 K8s 安全基线的第一层。企业环境中，最常见的风险不是某个用户完全没有权限，而是权限长期过大、角色复用混乱、临时授权没有回收。

评估重点： 管理员权限、命名空间权限、服务账号权限和自动化系统权限，都应纳入基线检查。尤其是生产环境中的高权限角色，不应只靠默认配置或人工约定管理。

最小授权： 每个角色只应拥有完成职责所需的权限。开发人员可以查看或发布指定应用，不代表可以修改集群级资源；流水线服务账号可以部署指定命名空间，不代表可以访问所有 Secret 或跨团队资源。

租户隔离： 多团队共用集群时，需要按命名空间、项目、业务系统或环境边界做权限隔离。隔离不是只分目录或命名空间，还要检查角色绑定、网络访问、资源配额和敏感配置访问方式。

可以用下面的清单检查身份权限基线。

从中可以看出，身份权限基线不只是 RBAC 配置项检查，更是对生产操作边界和团队职责的治理。

四、控制点 2：镜像供应链和准入检查

镜像是应用进入 K8s 环境的主要载体。镜像来源不清、基础镜像过旧、漏洞扫描无人处理、准入策略缺失，都会让风险直接进入运行环境。

镜像来源： 生产环境应明确允许哪些镜像仓库、哪些命名空间或哪些制品来源。临时拉取未知镜像、使用个人仓库镜像或绕过制品流程，都会削弱供应链安全。

扫描与处置： 镜像扫描不是为了生成报告，而是为了区分哪些风险需要阻断、哪些风险需要修复、哪些风险可以在例外审批后暂时放行。扫描结果应能关联镜像版本、应用、负责人和处置状态。

准入策略： 准入检查应把镜像来源、扫描结果、标签规范、签名或制品元数据纳入判断。不同企业成熟度不同，不一定一开始就强制所有策略，但至少要明确生产环境的最低门槛。

变更记录： 当某个镜像被放行或被拒绝，系统应能留下策略命中、审批和处置记录。否则后续很难判断一个风险镜像为什么进入生产。

镜像供应链基线可以先从“来源可信、结果可见、策略可执行、例外可追踪”4 个方面建立，再逐步扩展到更细的签名、SBOM 或制品元数据治理。

五、控制点 3：运行时防护和风险发现

即使镜像和权限在上线前通过检查，运行时仍然可能出现异常行为。K8s 安全基线需要覆盖运行中的资源边界、网络访问、异常行为和风险响应。

资源边界： Pod 是否设置合理的资源请求和限制，是否允许特权容器，是否挂载宿主机敏感路径，是否使用不必要的高权限能力，这些都应成为运行时基线的一部分。

网络边界： 生产环境中，不同命名空间、不同业务系统和不同访问方向应有基本边界。网络策略不一定一开始做到最细，但至少要能说明哪些访问是允许的，哪些访问应被限制或观察。

异常行为： 容器内异常进程、异常网络连接、频繁重启、异常权限使用和可疑文件变更，都可能提示运行时风险。企业可以根据自身成熟度选择监测方式，但不应完全依赖事后人工排查。

响应机制： 发现运行时风险后，需要明确谁确认、谁隔离、谁恢复、谁复盘。否则告警只会进入通知系统，不会真正变成治理动作。

运行时防护的基线不应追求一次覆盖所有攻击场景。更现实的做法是先保护生产命名空间、核心业务和高权限工作负载，再逐步扩大覆盖范围。

六、控制点 4：审计证据和持续复查

没有证据链的安全基线，很难长期运行。审计证据不是为了堆日志，而是让团队能回答：当时谁做了什么、策略如何判断、结果是否被处理、例外是否有依据。

操作证据： 权限变更、资源创建、策略修改、准入放行和回滚处置等关键操作应有记录。记录应能关联操作人、时间、对象和结果。

策略证据： 镜像准入、权限策略、运行时告警和网络策略命中结果，应能形成可查看的证据。只保留最终状态，不保留判断过程，会影响复查。

复查证据： 安全基线不是一次性验收项。企业应定期复查管理员权限、镜像风险、策略例外、运行时告警和长期未处理项，形成持续改进记录。

例外管理： 生产环境不可避免会遇到临时放行，但例外必须有原因、有效期、负责人和后续处理计划。没有有效期的例外，最终会变成长期风险。

审计证据的价值在于让安全治理从“已经做过”变成“可以证明、可以复查、可以改进”。

七、上线前检查清单：哪些项必须先确认

以下清单可用于 K8s 环境进入生产或重要业务上线前的安全基线检查。

从中可以看出，上线前检查不是把所有安全能力都做到最成熟，而是确保高风险入口已经被识别、控制和记录。

八、下一步建议

如果企业刚开始建立 K8s 安全基线，建议先从生产命名空间、管理员权限、镜像来源和审计日志 4 个入口做盘点。不要一开始就把所有安全能力都列成同等优先级。

先明确哪些项必须阻断，哪些项可以整改，哪些项需要例外审批。随后把检查结果和应用上线流程、发布流程、监控告警和复查机制连接起来。

如果团队已经有容器平台或 DevOps 平台，可以把安全基线嵌入日常发布链路。已经在做平台选型的团队，可以先回看 容器平台选型：5类核心能力评估与验收清单 中的安全与治理维度，再进入 云原生安全分类 持续补齐安全治理内容。

下步可以先选一个核心业务命名空间做样板，验证身份权限、镜像准入、运行时风险和审计记录是否能形成闭环，再逐步推广到更多生产工作负载。

SAQ：K8s安全基线常见问题

K8s安全基线第一步应该做什么？

第一步应先盘点生产命名空间、管理员权限、服务账号和镜像来源。企业需要先知道谁能操作哪些资源、哪些镜像能进入环境，再决定镜像扫描、准入策略和运行时检测的建设顺序。

K8s安全基线和容器安全有什么区别？

容器安全更关注镜像、运行时、隔离和漏洞等具体安全能力；K8s 安全基线更强调这些能力在 Kubernetes 环境中如何形成可执行的检查项、责任边界和审计证据。两者有关联，但基线更偏治理和验收。

镜像扫描通过就代表可以上线吗？

不一定。镜像扫描只是供应链安全的一部分。上线前还要看镜像来源是否可信、扫描结果是否有处置规则、运行参数是否合规、权限和网络边界是否可控，以及是否能留下准入和例外记录。

安全基线是否必须一次做到很完整？

不建议一开始追求面面俱到。更可行的方式是先覆盖生产环境、高权限账号、可信镜像来源、基础准入策略和审计日志，再根据业务风险逐步扩展到运行时检测、网络策略和更细的供应链治理。