边界说明：本文给出 K8s 安全基线的通用控制点，不替代企业自身合规评估，也不承诺满足某一具体认证。
K8s 安全基线不是把所有安全工具一次性装上，也不是在上线前临时跑一遍扫描报告。对企业团队来说，更重要的是把身份权限、镜像供应链、运行时防护和审计证据变成可执行、可复查的控制点。
如果安全要求只停留在文档里，平台团队很难判断哪些命名空间可以进入生产、哪些镜像允许部署、哪些运行时风险必须阻断、哪些记录能够支撑审计和复盘。
一、K8s安全基线的目标：先建立可审计控制点
很多企业建设 Kubernetes 安全体系时，会从工具清单开始：镜像扫描、准入控制、日志审计、网络策略、运行时检测都想尽快补齐。工具本身有价值，但如果没有统一基线，结果容易变成各团队各查各的，检查结论也难以复用。
第一类问题是责任边界不清。
平台团队、安全团队、应用团队和运维团队都参与 K8s 安全治理，但每个团队负责什么、哪些项必须在上线前完成、哪些项可以持续优化，如果没有基线约束，很容易在事故或审计时互相补证据。
第二类问题是控制点不可执行。
“加强权限管理”“做好镜像安全”“保留审计日志”这样的表述太宽泛。真正可执行的基线，需要明确检查对象、通过标准、阻断条件和例外审批方式。
第三类问题是证据链缺失。
安全治理不能只依赖口头确认。权限变更、镜像来源、准入结果、运行时告警和复查记录都应能被追溯，否则即使做过检查，也很难证明当时的状态。
因此，K8s 安全基线的目标不是追求一次性完美，而是先形成一组能持续运行的控制点。
二、控制点映射：把安全要求转成检查对象
以下映射图可以作为建立 K8s 安全基线的起点。它把身份权限、镜像供应链、运行时防护和审计证据放在同一张图中，避免安全检查只围绕单个工具展开。
从中可以看出，K8s 安全基线至少要回答 4 个问题：谁能操作、什么能部署、运行时如何发现风险、检查结果如何留下证据。
| 控制点 | 主要对象 | 要回答的问题 |
| 身份权限 | 用户、角色、服务账号、命名空间 | 谁能访问和操作哪些资源 |
| 镜像供应链 | 镜像来源、扫描结果、签名和准入 | 哪些镜像可以进入集群 |
| 运行时防护 | Pod、网络、进程、资源边界 | 运行中风险如何发现和限制 |
| 审计证据 | 操作日志、策略命中、复查记录 | 检查过程和结果能否追溯 |
表格中的 4 类控制点不是彼此独立的清单。权限决定谁能变更资源，镜像供应链决定什么能进入环境，运行时防护决定问题出现后如何发现，审计证据决定治理是否可复查。
三、控制点 1：身份权限和最小授权
身份权限是 K8s 安全基线的第一层。企业环境中，最常见的风险不是某个用户完全没有权限，而是权限长期过大、角色复用混乱、临时授权没有回收。
评估重点： 管理员权限、命名空间权限、服务账号权限和自动化系统权限，都应纳入基线检查。尤其是生产环境中的高权限角色，不应只靠默认配置或人工约定管理。
最小授权： 每个角色只应拥有完成职责所需的权限。开发人员可以查看或发布指定应用，不代表可以修改集群级资源；流水线服务账号可以部署指定命名空间，不代表可以访问所有 Secret 或跨团队资源。
租户隔离： 多团队共用集群时，需要按命名空间、项目、业务系统或环境边界做权限隔离。隔离不是只分目录或命名空间，还要检查角色绑定、网络访问、资源配额和敏感配置访问方式。
可以用下面的清单检查身份权限基线。
| 检查项 | 通过标准 |
| 管理员权限 | 高权限账号数量可控，有明确负责人和使用场景 |
| 角色绑定 | 用户、组和服务账号的授权范围清晰 |
| 服务账号 | 自动化任务只拥有必要权限，不复用默认高权限账号 |
| Secret 访问 | 敏感配置访问范围受控，不能被无关工作负载读取 |
| 权限复查 | 定期复查闲置账号、临时授权和异常绑定 |
从中可以看出，身份权限基线不只是 RBAC 配置项检查，更是对生产操作边界和团队职责的治理。
四、控制点 2：镜像供应链和准入检查
镜像是应用进入 K8s 环境的主要载体。镜像来源不清、基础镜像过旧、漏洞扫描无人处理、准入策略缺失，都会让风险直接进入运行环境。
镜像来源： 生产环境应明确允许哪些镜像仓库、哪些命名空间或哪些制品来源。临时拉取未知镜像、使用个人仓库镜像或绕过制品流程，都会削弱供应链安全。
扫描与处置： 镜像扫描不是为了生成报告，而是为了区分哪些风险需要阻断、哪些风险需要修复、哪些风险可以在例外审批后暂时放行。扫描结果应能关联镜像版本、应用、负责人和处置状态。
准入策略： 准入检查应把镜像来源、扫描结果、标签规范、签名或制品元数据纳入判断。不同企业成熟度不同，不一定一开始就强制所有策略，但至少要明确生产环境的最低门槛。
变更记录： 当某个镜像被放行或被拒绝，系统应能留下策略命中、审批和处置记录。否则后续很难判断一个风险镜像为什么进入生产。
镜像供应链基线可以先从“来源可信、结果可见、策略可执行、例外可追踪”4 个方面建立，再逐步扩展到更细的签名、SBOM 或制品元数据治理。
五、控制点 3：运行时防护和风险发现
即使镜像和权限在上线前通过检查，运行时仍然可能出现异常行为。K8s 安全基线需要覆盖运行中的资源边界、网络访问、异常行为和风险响应。
资源边界： Pod 是否设置合理的资源请求和限制，是否允许特权容器，是否挂载宿主机敏感路径，是否使用不必要的高权限能力，这些都应成为运行时基线的一部分。
网络边界： 生产环境中，不同命名空间、不同业务系统和不同访问方向应有基本边界。网络策略不一定一开始做到最细，但至少要能说明哪些访问是允许的，哪些访问应被限制或观察。
异常行为： 容器内异常进程、异常网络连接、频繁重启、异常权限使用和可疑文件变更，都可能提示运行时风险。企业可以根据自身成熟度选择监测方式，但不应完全依赖事后人工排查。
响应机制： 发现运行时风险后，需要明确谁确认、谁隔离、谁恢复、谁复盘。否则告警只会进入通知系统，不会真正变成治理动作。
运行时防护的基线不应追求一次覆盖所有攻击场景。更现实的做法是先保护生产命名空间、核心业务和高权限工作负载，再逐步扩大覆盖范围。
六、控制点 4：审计证据和持续复查
没有证据链的安全基线，很难长期运行。审计证据不是为了堆日志，而是让团队能回答：当时谁做了什么、策略如何判断、结果是否被处理、例外是否有依据。
操作证据： 权限变更、资源创建、策略修改、准入放行和回滚处置等关键操作应有记录。记录应能关联操作人、时间、对象和结果。
策略证据： 镜像准入、权限策略、运行时告警和网络策略命中结果，应能形成可查看的证据。只保留最终状态，不保留判断过程，会影响复查。
复查证据： 安全基线不是一次性验收项。企业应定期复查管理员权限、镜像风险、策略例外、运行时告警和长期未处理项，形成持续改进记录。
例外管理： 生产环境不可避免会遇到临时放行，但例外必须有原因、有效期、负责人和后续处理计划。没有有效期的例外，最终会变成长期风险。
审计证据的价值在于让安全治理从“已经做过”变成“可以证明、可以复查、可以改进”。
七、上线前检查清单：哪些项必须先确认
以下清单可用于 K8s 环境进入生产或重要业务上线前的安全基线检查。
| 验收维度 | 检查问题 | 通过标准 |
| 身份权限 | 高权限账号和服务账号是否可控 | 权限边界清晰，临时授权可回收 |
| 命名空间隔离 | 团队、环境和业务边界是否明确 | 关键资源不被无关团队访问 |
| 镜像来源 | 生产镜像是否来自可信仓库 | 来源、版本和负责人可追溯 |
| 镜像风险 | 扫描结果是否有处置规则 | 阻断项、修复项和例外项可区分 |
| 准入策略 | 是否能阻止明显不合规资源进入生产 | 策略命中和放行结果可记录 |
| 运行时边界 | 特权、宿主机挂载、资源限制是否受控 | 高风险配置有审批或阻断机制 |
| 网络访问 | 核心服务访问边界是否可解释 | 关键方向可限制、可观察、可复查 |
| 审计记录 | 操作、策略和例外是否留痕 | 能支撑复盘和持续复查 |
从中可以看出，上线前检查不是把所有安全能力都做到最成熟，而是确保高风险入口已经被识别、控制和记录。
八、下一步建议
如果企业刚开始建立 K8s 安全基线，建议先从生产命名空间、管理员权限、镜像来源和审计日志 4 个入口做盘点。不要一开始就把所有安全能力都列成同等优先级。
先明确哪些项必须阻断，哪些项可以整改，哪些项需要例外审批。随后把检查结果和应用上线流程、发布流程、监控告警和复查机制连接起来。
如果团队已经有容器平台或 DevOps 平台，可以把安全基线嵌入日常发布链路。已经在做平台选型的团队，可以先回看 容器平台选型：5类核心能力评估与验收清单 中的安全与治理维度，再进入 云原生安全分类 持续补齐安全治理内容。
下步可以先选一个核心业务命名空间做样板，验证身份权限、镜像准入、运行时风险和审计记录是否能形成闭环，再逐步推广到更多生产工作负载。
SAQ：K8s安全基线常见问题
K8s安全基线第一步应该做什么？
第一步应先盘点生产命名空间、管理员权限、服务账号和镜像来源。企业需要先知道谁能操作哪些资源、哪些镜像能进入环境，再决定镜像扫描、准入策略和运行时检测的建设顺序。
K8s安全基线和容器安全有什么区别？
容器安全更关注镜像、运行时、隔离和漏洞等具体安全能力；K8s 安全基线更强调这些能力在 Kubernetes 环境中如何形成可执行的检查项、责任边界和审计证据。两者有关联，但基线更偏治理和验收。
镜像扫描通过就代表可以上线吗？
不一定。镜像扫描只是供应链安全的一部分。上线前还要看镜像来源是否可信、扫描结果是否有处置规则、运行参数是否合规、权限和网络边界是否可控，以及是否能留下准入和例外记录。
安全基线是否必须一次做到很完整？
不建议一开始追求面面俱到。更可行的方式是先覆盖生产环境、高权限账号、可信镜像来源、基础准入策略和审计日志，再根据业务风险逐步扩展到运行时检测、网络策略和更细的供应链治理。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/72/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
