K8s安全基线怎么做？权限、镜像和运行时控制点

边界说明：本文讨论K8s安全基线的通用治理口径，不替代企业自身合规评估，也不承诺满足某一具体认证或审计要求。

K8s安全基线怎么做，不能只靠上线前安装一个扫描工具。企业更需要把权限、镜像、准入、运行时和审计证据变成可执行的控制点，让每个应用进入生产前都能回答：谁能操作，什么能部署，运行中如何发现风险，问题发生后能否追溯。

如果安全要求只停留在制度文档里，平台团队很难在发布、变更和排障过程中持续执行。基线的价值，是把安全要求转化为平台流程中的检查项和责任边界。

为什么K8s安全基线不能只看工具

很多团队建设Kubernetes安全体系时，会先想到镜像扫描、运行时检测、日志审计或网络策略。这些能力都有价值，但如果没有基线，工具之间容易各自为战。

例如镜像扫描发现了风险，但准入策略没有引用扫描结果，风险镜像仍然可能进入生产；RBAC配置看起来存在，但服务账号被长期授予过大权限；审计日志被采集了，但没人知道哪些操作需要复查。

因此，K8s安全基线至少要满足 3 个条件。

• 可执行：检查对象、通过标准和阻断条件清晰
• 可追溯：关键操作、策略结果和例外审批能留下证据
• 可持续：基线不是一次性验收，而是和发布、变更、监控、复查流程绑定

安全工具解决的是能力点，安全基线解决的是治理口径。企业需要先定义口径，再选择工具和平台能力承接。

控制点一：权限和身份边界

权限是K8s安全基线的第一层。生产集群中的高权限账号、服务账号、命名空间访问和自动化系统权限，都可能成为安全风险入口。

企业需要避免两类情况：一类是权限过大，开发、流水线或运维账号拥有不必要的集群级权限；另一类是权限不可追踪，临时授权、离职账号、默认服务账号和脚本凭据长期存在。

权限基线可以从以下检查项开始。

表格中的重点不是“是否配置了RBAC”，而是RBAC是否真的表达了组织、项目、环境和职责边界。对企业来说，权限基线应能支撑生产操作、审计复查和事故追溯。

控制点二：镜像来源和供应链风险

镜像是应用进入K8s环境的主要载体。镜像来源不清、基础镜像过旧、漏洞扫描无人处理、镜像标签混乱和制品流程绕过，都会让风险直接进入运行环境。

镜像供应链基线至少要回答 4 个问题。

第一，镜像来自哪里。生产环境应明确允许哪些仓库、哪些项目、哪些命名空间或哪些制品流程。个人仓库、临时镜像和未知来源镜像不应直接进入生产。

第二，镜像版本是否可追溯。企业需要知道某个应用发布时使用了哪个镜像、对应哪个构建记录、由谁触发、是否经过扫描和审批。

第三，风险如何处置。镜像扫描不是为了生成报告，而是为了区分阻断项、修复项、观察项和例外项。没有处置规则的扫描结果，很难进入发布决策。

第四，例外如何管理。某些风险可能因业务窗口或兼容性暂时放行，但例外应有原因、负责人、有效期和后续处理计划。

镜像基线的目标不是立即消除所有风险，而是让生产镜像的来源、版本、风险和处置状态都能被解释。

控制点三：准入策略把基线放进发布入口

准入策略是把安全基线从文档变成流程的关键环节。没有准入，权限、镜像、资源边界和安全规范往往只能依赖人工检查。

K8s准入控制可以用于检查镜像来源、资源限制、特权容器、宿主机挂载、命名空间标签、网络策略、运行用户和其他关键配置。企业不一定一开始就把所有策略设为强阻断，但至少要明确哪些项必须阻止进入生产。

比较稳妥的做法是分阶段推进。

1. 先观察：收集当前工作负载中高风险配置，了解真实影响范围。

2. 再告警：对不符合基线的资源给出提示和责任人。

3. 后阻断：对生产环境中的高风险项设置阻断或例外审批。

4. 持续复查：定期查看策略命中、例外放行和整改进度。

准入策略最怕“一刀切”。如果一开始策略过严，可能影响业务发布；如果长期只提示不阻断，又无法形成安全边界。企业应根据环境、业务等级和团队成熟度设定不同策略等级。

控制点四：运行时风险发现和响应

上线前检查无法覆盖所有风险。容器运行后，仍然可能出现异常进程、异常网络连接、权限滥用、资源异常、敏感路径访问、频繁重启和可疑文件变更。

运行时安全基线需要关注 3 类能力。

资源和配置边界。 工作负载是否设置资源请求和限制，是否启用不必要的特权能力，是否挂载宿主机敏感路径，是否使用高权限运行用户，这些都应纳入运行时基线。

行为和异常发现。 平台应能发现异常重启、异常网络访问、异常进程行为和策略违规事件。不同企业成熟度不同，监测方式可以逐步建设，但不应完全依赖事后人工排查。

响应和处置流程。 发现风险后，谁确认、谁隔离、谁回滚、谁通知业务、谁复盘，都需要提前定义。否则运行时告警只会增加噪音，不能真正降低风险。

运行时基线不应追求一次覆盖所有攻击场景。更现实的路径是先覆盖生产命名空间、核心业务、高权限工作负载和对外暴露服务，再逐步扩展。

控制点五：审计证据让治理可复查

没有证据链的安全基线，很难长期运行。企业不仅要做检查，还要能证明检查发生过、结果是什么、例外为什么被放行、后续是否处理。

审计证据通常包括 4 类。

从中可以看出，审计证据不是为了堆日志，而是为了让安全治理从“已经做过”变成“可以证明、可以复查、可以改进”。

上线前可以先做哪些检查

企业刚开始建立K8s安全基线时，不建议一开始把所有安全能力都列为同等优先级。可以先从生产环境和高风险入口做起。

建议优先确认以下事项。

• 生产命名空间、高权限账号和服务账号是否已盘点
• 生产镜像是否来自可信仓库，镜像版本是否可追溯
• 高风险配置是否有准入提示、阻断或例外审批
• 运行时异常是否能被监控、告警和分派处理
• 关键操作、策略命中和例外放行是否能留下记录
• 安全基线是否与应用发布、变更审批和故障复盘连接

这些检查不要求企业一次性达到最高成熟度，但至少要让平台团队知道当前风险在哪里，哪些项必须先补齐，哪些项可以持续优化。

常见误区

第一个误区是把K8s安全基线等同于镜像扫描。镜像扫描很重要，但它只是供应链的一部分，不能替代权限、准入、运行时和审计治理。

第二个误区是把安全责任全部交给平台团队。应用团队、平台团队、安全团队和运维团队都需要明确边界，尤其是镜像风险处置、权限申请、例外审批和故障响应。

第三个误区是只在上线前检查一次。K8s安全基线应随着应用发布、权限变化、镜像更新和策略调整持续运行，否则很快会失效。

下一步建议

如果企业正在建立K8s安全基线，建议先选择一个核心业务命名空间做样板，验证权限、镜像、准入、运行时和审计证据是否能形成闭环。样板跑通后，再推广到更多业务和集群。

如果当前还处于平台选型阶段，可以把安全基线作为容器平台POC的重要场景，而不是发布前补充项。重点验证平台是否能把安全控制点嵌入日常发布、运维和复查流程。

后续可继续阅读 云原生安全分类 下的容器安全、运行时防护和审计治理内容，把单篇检查项扩展为长期安全治理体系。

常见问题

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

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

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

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

准入策略是否应该一开始就全部阻断？

不建议。更稳妥的方式是先观察当前工作负载，再对高风险项告警和阻断。生产环境可以优先阻断明显高风险配置，同时为特殊场景设置有期限、有责任人的例外审批。

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

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