Kubernetes安全审计与合规并不是一个可以一次性完成的配置项，而是一条贯穿API Server请求记录、节点配置基线、工作负载运行时行为以及日志集中分析的完整链路。许多团队在完成集群部署后只开启了RBAC权限控制，就认为安全合规已经达标，但RBAC只解决谁能做什么的问题，并不记录谁实际做了什么。一旦发生越权访问或恶意操作，如果没有审计日志，排查将变得异常困难。因此，系统化地建设审计与合规能力，是生产集群必须优先完成的工作。
接下来，本文将围绕审计策略设计、合规基线检查和日志分析与告警三个核心环节展开，帮助读者构建一套可落地的Kubernetes安全审计合规体系。
一、审计策略与日志结构：记录每一个API请求
Kubernetes API Server是所有操作的统一入口，审计功能负责记录对API Server的请求。默认情况下，审计日志可能只记录很少的信息，或者根本没有开启。要启用审计，需要在kube-apiserver的启动参数中指定审计策略文件和日志后端。审计策略文件使用YAML格式，定义了哪些请求需要被记录以及记录的详细程度。
审计级别分为四种：None表示不记录，Metadata只记录请求的元数据（如用户、资源、操作、响应码），Request记录元数据和请求体，RequestResponse则同时记录请求体和响应体。对于生产环境，通常对敏感的写操作使用RequestResponse级别，对读操作使用Metadata级别，以平衡日志量和排查能力。以下是一个典型的审计策略示例：
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: None
resources:
- group: ""
resources: ["events"]
- level: Metadata
verbs: ["get", "list", "watch"]
resources:
- group: ""
resources: ["pods", "services", "configmaps"]
- level: RequestResponse
verbs: ["create", "update", "patch", "delete"]
resources:
- group: ""
resources: ["pods", "secrets", "serviceaccounts"]
- level: RequestResponse
userGroups: ["system:authenticated"]
resources:
- group: "rbac.authorization.k8s.io"
resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
上面的策略先排除了对events资源的审计，因为这类请求非常频繁且价值较低。对常见的读操作只记录元数据，而对Pod、Secret等资源的写操作以及RBAC对象的变更则记录请求和响应体。这样既能捕获敏感操作，又不会产生海量日志。审计日志的每一个事件都包含stage、requestURI、user、sourceIPs、verb、resource、responseStatus等字段，这些字段是后续分析和告警的基础。
二、合规基线检查：从CIS Benchmark到Pod安全标准
除了审计API请求，节点和工作负载的配置也需要符合安全基线。Kubernetes社区和业界广泛采用CIS Kubernetes Benchmark作为配置加固的参考。CIS Benchmark针对控制平面节点、工作节点、etcd等组件给出了数百条检查项，覆盖文件权限、参数配置、网络策略等方面。手动逐项检查非常耗时，因此可以借助kube-bench工具自动扫描集群，并生成合规报告。
kube-bench的使用很简单，可以在集群内以Job方式运行，也可以直接在节点上执行二进制文件。例如在控制平面节点上运行以下命令，可以对当前节点的配置进行检测：
kube-bench run --targets master --check 1.2.20,1.2.21
输出结果会标明每项检查是PASS、FAIL还是WARN，并给出修复建议。对于失败项，应根据环境评估风险后逐步整改。需要注意，某些CIS检查项可能过于严格，例如要求etcd客户端证书认证，可能在某些托管集群中不适用，因此需要结合实际情况制定内部基线。
在工作负载层面，Pod安全标准定义了privileged、baseline和restricted三个等级。从Kubernetes 1.22开始，可以使用Pod Security Admission（PSA）在命名空间级别强制实施这些标准。例如，给一个命名空间打上restricted标签，即可禁止创建以特权模式运行的Pod：
kubectl label namespace production pod-security.kubernetes.io/enforce=restricted kubectl label namespace production pod-security.kubernetes.io/warn=restricted
这样，任何试图在该命名空间创建不符合restricted策略的Pod都会收到警告或被拒绝。除了PSA，还可以使用OPA Gatekeeper或Kyverno等策略引擎实现更细粒度的合规规则，例如强制镜像来源、禁止挂载宿主机路径、限制容器能力等。这些策略可以作为集群准入控制的一部分，从源头阻断不合规的部署。
三、日志集中分析与运行时告警：从被动记录到主动发现
审计日志如果只是保存在API Server节点上的本地文件，其价值会大打折扣。一方面，攻击者可能会清理日志；另一方面，海量的日志无法通过人工逐条查看。因此，需要将审计日志集中采集到统一的日志平台，比如Elasticsearch、Loki或云厂商的日志服务。常见的采集方式是使用Fluent Bit或Filebeat读取审计日志文件，并转发到后端存储。
集中存储之后，可以基于审计日志构建告警规则。例如，当检测到某个ServiceAccount在短时间内大量创建Secret，或者有用户尝试访问默认命名空间中的kube-system资源，就可以触发安全告警。同时，运行时安全工具如Falco可以监控容器内的系统调用和文件访问，检测到异常行为时生成事件。将Falco事件与审计日志关联，可以还原攻击的完整链路：从最初的API调用到容器内的恶意操作。
下面是一个简单的Falco规则示例，用于检测容器内访问/etc/shadow文件的行为：
- rule: Read sensitive file desc: Detect attempts to read /etc/shadow condition: open_read and fd.name=/etc/shadow output: "Sensitive file read (user=%user.name file=%fd.name container=%container.name)" priority: WARNING tags: [filesystem, mitre_credential_access]
实际部署时，Falco可以作为DaemonSet运行在每个节点上，将告警输出到标准输出或直接发送到SIEM系统。结合审计日志中的subject信息，可以定位到具体的用户或ServiceAccount，从而进行权限收敛或账号禁用。此外，定期生成合规报表有助于跟踪整改情况，例如每周统计CIS检查通过率、PSA拒绝的Pod数量以及高危告警趋势。
最后需要强调的是，安全审计合规是一个持续的过程。集群版本升级、新业务上线、人员变动都可能引入新的风险，因此需要将审计策略、基线检查和告警规则纳入变更管理流程，并定期进行红队演练，验证整套体系的有效性。
Kubernetes安全审计合规基线审计策略修改时间：2026-08-27 11:29:42