Kubernetes安全审计：如何检查集群配置、权限与治理

设想一个假设的情境。一家虚构的B2B平台正准备接入一家大型企业客户。产品运行在多个Kubernetes集群上：每个客户分配独立的命名空间，部署通过GitOps完成，部分附加组件由托管服务提供商提供。客户在安全问卷中询问：其数据如何与其他租户隔离，公司内部谁能更改其环境的配置。技术总监很有把握：“每个客户都有自己的命名空间，所以一切都是隔离的。”平台负责人则没那么确定，但他无法迅速说明：谁通过哪些角色可以访问密钥，哪些Pod以提升的权限运行，网络策略是否真的拦截了任何流量。

这个情境是虚构的，但问题是真实的。回答它的不是又一个扫描器，而是一次配置与治理审计：检查集群中有什么、谁被允许做什么、哪些限制真正作用于工作负载、谁对这些限制负责，以及哪些成果物可以证明修复已经完成。下文介绍如何规划这样的审计、其结论的边界在哪里，以及最终应当验收什么。

Kubernetes配置与治理审计检查什么

在这里，Kubernetes安全审计指的是一种经授权的结构化评估，考察集群环境如何配置、由谁治理，以及其中哪些限制真正生效。单个应用测试只涉及一个层面。集群由多个层面构成，每个层面的失效方式各不相同：API访问、身份与角色绑定、工作负载配置、网络、密钥、审计日志以及镜像供应链。

这种审计与集群技术评估有何不同

这两类工作不应混淆。技术评估侧重发现并证实攻击路径，另一篇关于Kubernetes安全评估：范围、方法与优先级排序的文章专门讨论了它。配置与治理审计回答的是一个相邻但不同的问题：集群的实际状态是否与组织所认定的控制措施一致，每项控制是否都有负责人和有效运行的证据。它更多依赖审阅清单文件、策略和绑定，而非主动利用；其主要成果不是漏洞清单，而是一张权限、限制与责任的地图，并附有可检验的验收标准。

资产清单是第一项成果

审计从“到底有什么”这个问题开始。这包括集群及其版本、命名空间及其用途、节点与节点池、已安装的Operator、控制器和准入Webhook、网络插件、密钥的存储方式、镜像来源以及接入的外部身份系统。没有这份清单，就无法诚实地说明哪些内容在范围之内。清单应连同版本和快照日期一起记录：集群经常被重新配置，没有日期的快照很快就会失去证据价值。往往仅在这一步，就会发现被遗忘的测试命名空间、无人负责的Operator，或者一个没人当作生产环境的集群。

四条不能混为一谈的边界

讨论Kubernetes安全时最常见的错误，是把“隔离”当作单一属性。实际上，审计人员至少要检查四条不同的边界，每条边界都依赖各自的机制。

第一条是控制平面权限：谁能通过API读取、创建和修改对象。第二条是工作负载身份：Pod以哪个服务账户运行，以及该账户在API和外部系统中能做什么。第三条是容器运行时与主机隔离：容器中的进程与主机内核和文件系统隔离得有多彻底。第四条是网络强制执行：Pod、服务与外部世界之间的哪些连接真正被阻断。

为什么命名空间不是强隔离

Kubernetes命名空间是在单个集群内对API对象进行分组和划定范围的机制。它定义了名称作用域，也是绑定角色、配额和策略的便利锚点。它本身既不提供网络隔离，也不提供内核隔离。Kubernetes关于多租户的文档明确指出，命名空间隔离模型需要配置若干其他资源和网络插件，并遵循安全最佳实践。默认情况下，集群中的Pod之间可以相互通信，而容器仍是共享节点内核的进程。

因此，“每个客户一个命名空间”描述的是组织层面的边界，而不是经过证明的隔离。要让它成为安全边界，需要严格受限的RBAC授权、禁止访问集群级资源、由插件实际执行的网络策略、在准入阶段对工作负载的限制；对于互不信任的租户，还需要节点隔离或沙箱。

RBAC：看授权内容，而不是角色名称

身份与访问首先接受审查，因为集群API控制着其他一切。对于每个主体，审计人员需要回答三个问题：哪些身份能够通过认证，采用什么机制，以及每个身份认证后被允许做什么。“readonly”或“developer”之类的名称什么也保证不了：真正重要的只有Role和ClusterRole对象中的规则，以及这些规则绑定给了谁。

危险动词与间接提权路径

有些权限的危险不在于直接作用，而在于其后果。在某个命名空间中创建Pod的权限，实际上允许以该命名空间中的任意服务账户启动Pod，并挂载其中任意密钥；Kubernetes文档在密钥一节中专门对此提出了警告。

针对escalate、bind和impersonate这几个动词的授权需要格外关注：视其作用范围和目标对象而定，它们可能导致权限提升，例如创建或绑定比自身更宽的角色，或以其他主体的身份行事。但这并不是自动成立的结论：仅限于某个命名空间中一个窄角色的bind权限，或仅限于特定服务身份的impersonate权限，需要根据实际能够触及的内容来评估。

资源或动词中的通配符授予的权限超出预期，并会在出现新的资源类型时自动扩大。通过list和watch读取密钥，与通过get读取同样重要。

还要分清角色是通过哪个对象授予的。ClusterRoleBinding在整个集群范围内授予ClusterRole的权限，即作用于所有命名空间以及集群级资源。RoleBinding也可以引用ClusterRole，但此时权限只在该RoleBinding所在的命名空间内生效：这样可以在不同命名空间复用同一个标准角色，而不扩大其作用范围。混淆这两种情况的风险是双向的：既可能漏掉集群级授权，也可能高估局部授权的严重性。来自外部身份提供商的用户组同样需要仔细审查。

服务账户与工作负载身份

每个Pod都以某个服务账户运行。如果令牌被自动挂载，而工作负载并不需要它，那么任何在容器中获得代码执行能力的人，也就获得了该账户的权限。审计会记录使用了哪些账户、哪些地方关闭了自动挂载、默认账户有哪些绑定，以及工作负载身份如何关联到云端或外部角色。最后这一环往往是从集群通向外部最宽的路径，如果只看RBAC，很容易遗漏。

工作负载与准入控制

Pod配置决定了容器与节点耦合的紧密程度。审计人员会查看特权模式、额外添加的内核能力、主机路径挂载、是否使用主机的网络、PID或IPC命名空间、是否以root运行、是否允许权限提升、seccomp和AppArmor配置文件，以及根文件系统是否只读。

特权Pod是发现，而不是逃逸的证据

特权Pod或挂载主机根目录是严重的发现：这样的配置移除了容器与节点之间的大部分屏障。但这还不能证明存在可通过内核漏洞利用的逃逸。配置层面的发现说明边界被削弱或缺失；而要主张发生了逃逸，则需要单独的授权测试、可复现的条件以及证据。报告必须区分这两个层次：“工作负载X未落实节点隔离”与“已演示突破到节点”是两个不同的结论，后果也不同。如果目标是专门证实突破的可能性，那就是另一类工作，详见关于容器逃逸渗透测试的文章。

准入策略是强制执行点

如果没有任何机制阻止明天部署一个配置错误的Pod，那么单个Pod配置正确的意义就很有限。因此，审计会检查准入控制：内置的Pod Security Admission及其privileged、baseline和restricted三个级别，或外部策略引擎。关键问题包括：策略以何种模式运行（enforce、audit或warn），覆盖哪些命名空间，授予了哪些豁免、由谁授予、期限多长，以及Webhook不可用时会发生什么。warn模式属于检测性控制：它能暴露违规，但不会阻止部署，因此不是预防性控制。报告中不应把它当作强制执行。准入Webhook和Operator本身也是拥有广泛权限的代码，它们自身的绑定同样在审计范围内。

网络、密钥与出站流量

NetworkPolicy只有在插件支持时才生效

NetworkPolicy对象只是一种意图声明。Kubernetes文档指出，网络策略由网络插件实现，在没有实现它的控制器的情况下创建NetworkPolicy不会产生任何效果。因此，审计人员要同时检查三件事：所安装的插件是否支持策略，各命名空间是否有默认拒绝策略，以及选择器是否与Pod的实际标签一致。没有默认拒绝时，未被任何策略选中的Pod仍对入站连接开放。检查不能止步于阅读YAML：在两个Pod之间做一次简短且事先约定的连接测试，就能看出规则是否真正生效。

密钥：谁实际上能读取

默认情况下，Kubernetes密钥以未加密形式存储在etcd中，任何拥有相应权限的API访问者或能够访问etcd的人都可以读取。因此，密钥审查归结为实际访问的问题：是否启用了静态加密，谁能直接读取密钥，谁能创建Pod并借此挂载密钥，密钥值是否被排除在日志、镜像和代码仓库之外，密钥如何交付给工作负载——通过卷还是环境变量——以及所选方式是否符合威胁模型和潜在暴露面，是否使用外部存储，以及工作负载如何向外部存储进行认证。发现的任何密钥值都只以对象引用的方式记录，不得复制，并通过约定渠道交给所有者。

出站流量是独立的范围边界

出站流量常被忽视：规则是为入站连接编写的，而出站一律放行。对审计而言，这意味着两件事。第一，要检查那些不需要访问互联网或云节点元数据服务的工作负载，其出站是否受到限制。第二，出站是工作范围的问题：如果测试人员要检查Pod能否访问外部，必须事先约定哪些外部地址可以作为测试目标，以及发现意外路由时该怎么做。否则，即使是无害的连接检查，也可能触及第三方系统。

方法：从授权到预发布环境测试

NIST SP 800-115依然为流程提供了良好的规范。其正式的评估过程分为规划、执行和执行后活动。对于集群审计，可以采用对这一框架的编辑性改编：规划、实施检查与测试、分析发现、修复与复测。这是一种实践顺序，而非NIST的官方模型。该指南早于容器编排的普及，因此从中汲取的是流程规范，而具体的集群配置项则来自审计团队自行获取并核实的最新平台文档和加固指南。

书面授权与停止条件

工作始于系统所有者的书面授权。授权书列明纳入范围的集群、命名空间、账户和环境，以及允许使用的技术、测试时间窗口和停止条件。任何框架都不会自动授予这种授权。对于托管平台，团队还要核实提供商条款允许做什么，并记录哪些控制平面组件按定义无法接受审查。

先阅读，再做有针对性的测试

SP 800-115把检查——审阅文档、配置和日志——与主动作用于系统的测试区分开来。对集群而言，这一区分至关重要。以只读方式审阅清单文件、角色绑定、准入策略和审计日志，几乎不带来运营风险。而在生产环境中采取主动操作，可能影响共享基础设施的可用性。较稳妥的顺序是先检查，再在预发布副本上或在约定范围内进行有针对性的测试，并且只在测试能够回答阅读无法回答的问题时才进行。

1. 授权所有者以书面形式记录集群、命名空间、账户、技术、时间窗口和停止条件。
2. 资产清单团队描述集群、版本、Operator、Webhook、网络插件和密钥存储方式，并注明快照日期。
3. 配置审阅以只读方式分析RBAC、服务账户、Pod安全上下文、准入策略和网络策略。
4. 针对性测试仅针对阅读无法回答的问题，在约定范围内执行主动检查。
5. 验收与复测每项发现都有负责人、关闭标准和对修复的再次检查。

证据管理

为确保可复现，应记录集群和组件版本、每项操作所用的身份以及时间戳。关于权限的结论，不应只依靠角色导出，还应以具体主体的身份进行访问检查：这能迅速揭示角色的设计意图与其实际允许的操作之间的差距。

归属与治理：每项发现都要有负责人

配置审计的价值，取决于其结果能否到达有能力做出改变的人手中。因此，每个集群、命名空间、Operator和策略都要记录负责人。没有负责人的发现几乎必然会一直处于未关闭状态。

把发现视为相对目标成果的差距，而非检查清单的失败项

基准式检查给出清晰的通过或未通过结果，但并非每一项未通过的检查对业务都同样重要。NIST CSF 2.0允许把结果表述为相对组织目标成果的差距：管理层能看到哪些差距影响风险态势，而工程师仍能得到精确、可测试的条目。反复出现的配置错误应推动模板、策略或流水线的修改，而不是手动修改某一个清单文件。如果集群以代码方式定义，那么修改模板本身就是修复根因；如何审查这类模板，可参阅关于基础设施即代码安全评估的文章。

托管平台与供应商

许多集群运行在托管平台上，并使用第三方插件，因此部分治理责任在供应商一侧。CISA的“安全设计”原则主张，产品应默认安全，并免费提供多因素认证、日志记录和单点登录。“按需安全”指南鼓励客户在采购时提出相应问题，审计团队也可以采用同样的思路：默认启用了什么，控制平面审计日志是否无需额外许可即可使用，供应商如何应对各类漏洞。这些答案应连同文档证明一并纳入审计记录，而不能仅凭口头说法。

发现的优先级排序

集群会产生很长的发现清单，优先级排序决定了审计能否带来任何改变。

通往权限的路径比常规卫生问题更重要

排在最前面的是能够串成路径的发现：创建Pod的权限加上特权上下文，再加上缺少准入策略；权限范围很广的令牌加上开放的出站流量。孤立的卫生问题，例如缺少标签或资源限制设置欠佳，排序较低，即使这类条目很多。对于平台自身的代码——控制器、Operator、准入Webhook——借助CWE Top 25的弱点类别视角很有帮助：这些代码的缺陷可以映射到CWE类别，而MITRE指出，命令注入等弱点会吸引攻击者的关注。

集群审计的边界在哪里

运行在集群中的应用是整体图景的一部分，但对其审查属于另一个层面。如果某个应用依赖网络策略、Ingress的TLS或密钥存储，这些平台控制就属于基于OWASP ASVS的验证范围；引用要求时应附带版本标签，例如v5.0.0-1.2.5，因为标识符会随版本变化。OWASP Top 10适合用来与开发团队讨论风险，但不能替代验证标准。

验收：哪些成果物能够结束审计

审计并不是在报告发出时完成，而是在每项重要发现都明确了由谁关闭、以何种证据确认之后才算完成。

复测，并把检查转化为控制

只有使用发现问题时的同一方法进行再次检查，并记录版本和日期，修复才算得到确认。如何证明修复真正有效，详见关于渗透测试修复验证的文章。由于集群经常被重新配置，单次快照很快就会过时：SP 800-115提到要设计、实施并维护测试与检查流程。最有价值的审计检查值得转化为可重复执行的规则——写入准入策略、写入流水线，或纳入定期的权限核对。

审计和渗透测试不是什么

配置审计和渗透测试提供的是关于系统在检查时点、在约定范围内状态的证据。它们不是鉴证，不是认证，也不是审计师对控制措施充分性的意见。报告可以成为提交给监管机构或客户的材料，但关于合规的结论应由有权作出结论的一方作出。

采购方的决策

内部团队完全有能力开展持续的配置检查。当范围较大、需要向客户或监管机构提供证据，或者内部团队本身就是待审平台的建设者时，独立评估尤其有用。无论哪种方式，审计质量更多取决于授权、证据管理的规范性以及管理层可据以行动的优先级排序，而不是工具本身。

启动前需要准备什么

回到开头那个假设的平台。在答复客户之前，它应先确定自己究竟要主张什么：是按命名空间进行的组织层面划分，还是对互不信任租户的隔离。范围、主动测试是否可以接受以及验收成果物的组成，都取决于这一点。最好事先准备好集群及其负责人清单、租户模型说明、角色和绑定的导出、注明所用插件的准入策略和网络策略清单，以及托管平台提供商的条款。有了这些材料，与任何服务商开始沟通都会更顺畅；Pentest.red上的渗透测试范围准备页面可以帮助整理这些内容。