安全口径：本文讨论企业云原生平台和K8s生产环境中的安全治理控制点，不替代正式合规咨询，也不承诺某个平台能天然满足所有监管要求。
云原生安全怎么做，不能只理解成“上线前扫描一次镜像”。企业进入Kubernetes、容器平台和微服务架构后，风险会分布在镜像供应链、集群权限、网络访问、运行时行为、配置密钥、发布流程和审计证据中。任何一个环节缺失，都可能让安全治理变成事后补救。
很多人搜索“云原生技术有哪些”，会看到容器、K8s、微服务、服务网格、DevOps、可观测和安全等技术名词。真正落到企业云原生架构中，安全不是其中一个独立模块，而是要嵌入构建、发布、运行和运维的日常流程。
云原生安全和传统安全有什么不同
传统安全更多围绕主机、网络边界、账号和应用漏洞展开。云原生环境仍然需要这些能力，但风险形态发生了变化：应用以容器运行，基础设施由声明式配置管理，服务动态伸缩，权限通过Kubernetes资源和角色绑定控制，镜像和依赖链路成为新的供应链入口。
这意味着安全团队不能只在上线前做一次扫描，也不能只依赖外部边界防护。云原生安全要更靠近研发、交付和运行流程：镜像构建时要控制来源，部署前要检查配置，运行时要发现异常，操作后要留下审计证据。
对于平台团队来说，安全治理的目标不是增加一堆额外审批，而是把安全控制点做成平台能力。研发团队按标准接入，安全规则在流水线、准入、权限、运行时和告警中自动生效。
控制点1：镜像供应链和制品可信
镜像是云原生应用进入运行环境的关键载体。如果镜像来源不可信、依赖漏洞不可见、制品版本不可追踪，后续运行时防护会非常被动。
镜像供应链控制至少要回答几个问题：镜像来自哪个代码提交，构建过程是否可追踪，基础镜像是否可信，依赖漏洞是否扫描，扫描结果是否能阻断高风险发布，镜像仓库是否有权限和保留策略，生产环境是否只允许使用受控仓库中的镜像。
企业常见误区是“扫过就算安全”。扫描只能发现一部分已知问题，还需要配合修复流程、风险豁免、版本追踪和准入策略。否则扫描报告会堆积，真正发布时仍然无法判断风险是否可接受。
镜像安全的验收口径不应只是有没有扫描工具，而是能否从生产Pod追溯到镜像、制品、构建任务和代码提交，并能说明关键漏洞是否处理或经过审批。
控制点2：K8s权限和多租户隔离
Kubernetes权限治理是云原生安全的核心。RBAC、命名空间、ServiceAccount、准入策略和审计日志共同决定了谁能操作集群、能访问哪些资源、能否影响生产环境。
权限问题最容易在平台初期被忽略。为了方便调试，团队可能给开发者过高权限；为了快速上线，多个应用共享命名空间；为了减少配置，生产和测试环境角色边界不清。短期看效率高，长期会形成很大的安全和审计风险。
平台应按团队、环境、应用和操作类型划分权限。开发环境可以更灵活，生产环境必须更严格；查看权限、发布权限、配置修改权限和集群管理权限应分开；高风险操作需要审批、留痕或临时授权。
如果企业正在做K8s安全基线，可以继续阅读 K8s安全基线怎么做？权限、镜像和运行时控制点 ，先把权限、镜像、网络和运行时的底线能力梳理清楚。
控制点3：网络隔离和服务访问边界
云原生架构中服务之间的调用更频繁，网络边界也更动态。只依赖传统边界防火墙，很难覆盖命名空间、服务、Pod和服务间调用层面的访问关系。
网络隔离要回答：哪些命名空间可以互访，哪些服务只允许内部访问，哪些出口流量需要控制，哪些管理接口不能暴露，服务间通信是否需要加密，入口网关和内部服务治理如何分工。
对于微服务场景，API网关通常负责外部入口，服务网格或网络策略负责服务间通信，Kubernetes网络策略负责基础隔离。三者不是互相替代关系，应根据风险和复杂度分层使用。
这里要避免“一上来就全量服务网格”的过度设计。服务数量少、调用关系简单时，可以先建立命名空间隔离、入口治理和基础网络策略；当服务间策略复杂、安全通信要求提升时，再评估服务网格能力。
控制点4：运行时防护和异常发现
即使镜像和权限做了控制，运行时仍可能出现异常行为，例如容器尝试提权、访问异常路径、发起异常网络连接、执行不符合预期的命令，或因为配置错误暴露敏感信息。
运行时防护关注的是应用真正跑起来之后发生了什么。平台至少需要能够观察容器状态、进程行为、网络连接、资源异常、重启事件、告警和关键操作。对于高风险应用，还应有异常告警、隔离、暂停或人工介入流程。
运行时安全不能和可观测系统割裂。安全告警如果无法关联应用、命名空间、版本、发布记录和负责人，就很难形成处理闭环。反过来，普通监控如果缺少安全上下文，也可能忽略异常行为。
运行时防护的目标不是制造更多告警，而是让高风险行为能被发现、定位、处置和复盘。
控制点5：审计证据和持续治理
很多企业在合规或内审阶段才发现，系统里有策略，但缺少可证明的证据。云原生安全不仅要“做了控制”，还要能说明控制何时生效、谁操作过、哪些风险被阻断、哪些例外被批准。
审计证据可以包括：镜像扫描结果、构建和发布记录、RBAC变更记录、生产操作审计、准入策略命中记录、网络策略变更、运行时告警、漏洞处理记录和风险豁免审批。
这些证据最好由平台自动生成，而不是靠人工补文档。人工补证据容易遗漏，也难以反映真实状态。平台化治理可以把安全控制点嵌入流水线、准入控制、权限系统、监控告警和审计日志中。
云原生安全控制点清单
企业可以用以下清单做初步评估。
| 控制点 | 需要回答的问题 | 常见风险 |
| 镜像供应链 | 镜像来源、漏洞、构建和制品能否追踪 | 镜像带漏洞或来源不明 |
| K8s权限 | 谁能操作集群、命名空间和生产资源 | 高权限账号滥用或误操作 |
| 网络隔离 | 服务、命名空间和出口访问是否受控 | 横向访问扩大故障和攻击面 |
| 运行时防护 | 异常进程、网络和资源行为能否发现 | 入侵或异常行为长期不可见 |
| 审计证据 | 控制点是否有记录、审批和复盘材料 | 合规检查时无法证明执行情况 |
这份清单可以作为安全建设起点，也可以用于平台选型、POC和上线前检查。不同企业的监管要求不同，但这些控制点通常都需要被纳入长期治理。
云原生架构中的安全落点
云原生架构常见技术包括容器、Kubernetes、微服务、服务网格、DevOps、可观测、镜像仓库、CI/CD和运行时安全。安全落点不是把每个技术都买一遍，而是把关键控制嵌入架构链路。
在构建阶段，关注代码依赖、基础镜像、镜像扫描和制品签名；在发布阶段，关注准入策略、权限审批、环境隔离和回滚；在运行阶段，关注网络访问、运行时异常、日志指标和告警；在治理阶段，关注审计证据、策略变更和风险复盘。
如果企业正在规划整体云原生平台，也可以参考 云原生平台建设：从K8s底座到治理平台的3个阶段 ，把安全控制点放进平台演进路线中。
下一步建议
企业做云原生安全治理时，不建议从“大而全”的工具清单开始。更可执行的方式，是先选取一个生产集群或一组关键应用，按镜像、权限、网络、运行时和审计证据五类控制点做差距评估。
如果缺口集中在发布前，可以先补镜像扫描、准入策略和制品追踪；如果缺口集中在运行中，可以补运行时告警、网络隔离和权限审计；如果缺口集中在合规复查，可以优先打通证据链。更多内容可以进入 云原生安全分类 继续阅读。
常见问题
云原生安全是否等同于K8s安全？
不等同。K8s安全是云原生安全的重要部分，主要覆盖集群权限、工作负载、网络、准入和运行时等内容。云原生安全范围更大，还包括镜像供应链、CI/CD、微服务、可观测、审计证据和组织流程。
云原生技术有哪些和安全有什么关系？
容器、Kubernetes、微服务、服务网格、DevOps和可观测等技术都会带来新的安全控制点。企业不应只记技术名词，而要判断每类技术在构建、发布、运行和审计流程中对应哪些风险和治理动作。
镜像扫描能解决所有供应链风险吗？
不能。镜像扫描只能发现一部分已知漏洞和配置问题，还需要配合基础镜像治理、制品追踪、准入策略、修复流程和风险豁免。没有这些流程，扫描结果很容易停留在报告层面。
云原生安全建设最容易遗漏什么？
最容易遗漏审计证据和运行时闭环。很多团队配置了权限和扫描，但无法证明策略是否持续生效，也无法在异常发生时关联应用、版本、负责人和处置记录。这会影响故障复盘和合规检查。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/157/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
