审计级别的选择：可见性与性能的权衡
Kubernetes API Audit 机制用于记录集群控制面接收到的所有 API 请求与响应，是安全合规与故障排查的核心组件。每条审计事件以 JSON 格式输出，包含请求时间戳、发起用户（User/Group）、目标资源（API Group/Version/Resource）、请求动词（Verb）、源 IP 以及响应状态码等关键字段。Kubernetes 提供四种审计级别：None 不记录任何事件；Metadata 仅记录请求元数据（如用户、时间、资源），不包含请求体与响应体；Request 额外记录请求体内容；RequestResponse 则完整记录请求与响应体。在生产环境中，全量开启 RequestResponse 会导致日志体积暴增并显著增加 API Server 的序列化开销，通常建议对核心资源（如 Secret、ConfigMap）使用 Metadata 或 Request，对常规 Pod/Deployment 操作使用 Metadata，并在合规要求严格时按需开启 RequestResponse，以平衡安全可见性与集群性能。
编写 Audit Policy：优先级与敏感信息过滤
审计策略通过 audit-policy.yaml 定义，采用自上而下的规则匹配机制，一旦命中某条规则即停止向下匹配，未命中的请求将应用 rules 末尾的 fallback 规则。编写策略时，应优先将高敏感或高频操作前置。例如，可针对 secrets 资源设置 Request 级别以捕获创建/更新内容，对 pods 设置 Metadata 级别，对 system:serviceaccount 发起的常规心跳请求设置 None 级别以降低噪音。策略结构包含 apiVersion、kind: Policy 及 rules 数组，每条规则通过 resources、namespaces、users 或 verbs 进行过滤。为避免记录敏感信息（如密码、Token），切勿对包含认证凭据的 /login 或 /token 接口启用 RequestResponse，同时可利用 omitStages 字段过滤 RequestReceived 阶段，仅保留 ResponseComplete 阶段的最终结果，从而有效缩减日志体积并规避合规风险。
启用 API Server 审计：配置注入与权限检查
启用 API Server 审计日志的核心在于向 kube-apiserver 注入审计策略文件路径与日志输出参数。在基于 kubeadm 部署的集群中，API Server 以静态 Pod 形式运行于 /etc/kubernetes/manifests/kube-apiserver.yaml。需在该文件的 command 或 args 中添加 --audit-policy-file=/etc/kubernetes/audit/audit-policy.yaml 与 --audit-log-path=/var/log/kubernetes/audit/audit.log。同时，必须通过 volumeMounts 和 volumes 将宿主机的策略文件目录与日志目录挂载至容器内，确保 API Server 进程具备读写权限。修改 manifest 后，kubelet 会自动检测文件变更并重启静态 Pod。若使用二进制部署，则需在 systemd 启动参数中追加对应标志。注意日志目录需提前创建并设置 chown -R kube:kube 权限，否则 API Server 将因无法写入日志而启动失败。
验证与运维：从实时观测到日志轮转
验证审计功能是否正常，可通过执行明确的 API 操作并实时观察日志输出。例如运行 kubectl get pods -n default 后，使用 tail -f /var/log/kubernetes/audit/audit.log 检查是否生成包含 requestURI、user.username 及 responseStatus.code 的 JSON 事件。若日志未生成，需按顺序排查：首先确认 audit-policy.yaml 路径在容器内可访问且语法正确（可用 kubectl apply --dry-run=client -f 校验）；其次检查宿主机日志目录权限与磁盘空间，避免 Permission denied 或 No space left on device；再次确认 kube-apiserver 进程参数是否生效（ps aux | grep audit）；最后，生产环境必须配置日志轮转（如 logrotate），否则单一日志文件会撑爆磁盘。可设置 maxsize 100M 与 rotate 7，并配合 copytruncate 避免中断 API Server 写入流。
