设计审计策略

目标

逐条添加规则，构建 audit.k8s.io/v1 审计策略文件，并亲自确认规则顺序和级别选择会保留什么、丢弃什么。

为什么重要

事件响应的第一个问题永远是“何时、谁、做了什么”，而在 Kubernetes 中，唯一能回答这个问题的资料就是 API 服务器审计日志。全部记录会导致成本爆炸，随意记录则会在真正需要时一无所获。因此，审计策略并不是决定“记录什么”的文档，而是决定“丢弃什么”的文档。

本实验会让你亲自经历两个最常见的错误。第一，规则自上而下评估，只应用第一个匹配项，因此排除规则（level: None）放在下方时完全无效。第二，如果对 Secret 使用 RequestResponse，秘密值会原样进入审计日志文件。审计日志收集系统通常比应用拥有更广的访问权限，结果反而会把原本要保护的内容扩散出去。

此环境无法真正启用审计日志（kwok 控制平面无法重新挂载策略文件）。评分只检查策略文件的内容和顺序。CKS 考试最终检查的也是这个文件。Falco 规则以及使用 crictl 进行的运行时调查，会在本模块的阅读和测验中讲解。

步骤

创建 /root/cks-audit-runtime/audit-policy.yaml。设置 apiVersion: audit.k8s.io/v1、 kind: Policy；rules 的最后一条必须是不带任何条件、level: Metadata 的兜底规则。
在同一文件的顶层添加 omitStages，并加入 RequestReceived。
在 rules 中添加以 level: Metadata 记录 Secret 和 ConfigMap 的规则。目标是核心组中的 secrets 和 configmaps。文件中的任何规则都不得针对 secrets 指定 Request 或 RequestResponse。
在 rules 的最顶部加入排除规则，忽略 kube-system 命名空间中对 secrets 的 get 请求，并将其设置为 level: None。该规则必须位于第 3 步创建的规则之前。
在 rules 中添加规则，对 RBAC 资源（rbac.authorization.k8s.io 组中的 roles、rolebindings、 clusterroles、clusterrolebindings）的 escalate、bind、impersonate 动词使用 level: RequestResponse 记录。
在 rules 中添加规则，对核心组 pods 的 create、update、patch、delete 使用 level: Request 记录。
在 /root/cks-audit-runtime/apiserver-audit-flags.txt 中逐行写入要添加到 API 服务器的标志。共五项：--audit-policy-file=/etc/kubernetes/audit-policy.yaml、 --audit-log-path=/var/log/kubernetes/audit.log、--audit-log-maxage=30、 --audit-log-maxbackup=10、--audit-log-maxsize=100。

参考

单条规则的结构：在 - level: None 下按需添加 resources、namespaces、verbs。
resources 项是由 - group: "" 与 resources: [...] 组成的列表。核心组使用空字符串。
使用 yq '.rules | length' /root/cks-audit-runtime/audit-policy.yaml 查看规则数量，更容易检查顺序。
常见错误 1：把 level: None 排除规则放在文件下方。上方规则会先匹配，使其完全无效。
常见错误 2：把兜底规则放在最上方。这样下面的规则永远不会被评估。

审计策略骨架与兜底规则

创建 /root/cks-audit-runtime/audit-policy.yaml。设置 apiVersion: audit.k8s.io/v1、 kind: Policy；rules 的最后一条必须是不带任何条件、level: Metadata 的兜底规则。

该策略是 audit.k8s.io/v1 的 Policy 资源。用于接收未被任何规则匹配请求的兜底规则必须放在最底部。

移除噪声阶段

在同一文件的顶层添加 omitStages，并加入 RequestReceived。

一个请求会在多个阶段产生事件。收到请求时的事件通常没有用处。将它指定为顶层字段即可应用于整个策略。

Secret 只记录到元数据级别

在 rules 中添加以 level: Metadata 记录 Secret 和 ConfigMap 的规则。目标是核心组中的 secrets 和 configmaps。文件中的任何规则都不得针对 secrets 指定 Request 或 RequestResponse。

如果对 Secret 使用 Request 或更高级别，秘密值会原样进入审计日志文件。任何规则都不得针对 secrets 指定 Request 或更高级别。

排除 kube-system 噪声

在 rules 的最顶部加入排除规则，忽略 kube-system 命名空间中对 secrets 的 get 请求，并将其设置为 level: None。该规则必须位于第 3 步创建的规则之前。

规则自上而下评估，只应用第一个匹配项。如果排除规则位于下方，就会先被上方规则捕获。

完整记录权限提升尝试

在 rules 中添加规则，对 RBAC 资源（rbac.authorization.k8s.io 组中的 roles、rolebindings、 clusterroles、clusterrolebindings）的 escalate、bind、impersonate 动词使用 level: RequestResponse 记录。

RBAC 资源不在核心组中，而属于 rbac.authorization.k8s.io 组。请在 verbs 中写全三个高风险动词。

Pod 变更记录到请求正文

在 rules 中添加规则，对核心组 pods 的 create、update、patch、delete 使用 level: Request 记录。

排除读取操作，只选择变更动词。保留请求正文后，便可在入侵后重建部署过的清单。

综合：记录审计日志后端标志

在 /root/cks-audit-runtime/apiserver-audit-flags.txt 中逐行写入要添加到 API 服务器的标志。共五项：--audit-policy-file=/etc/kubernetes/audit-policy.yaml、 --audit-log-path=/var/log/kubernetes/audit.log、--audit-log-maxage=30、 --audit-log-maxbackup=10、--audit-log-maxsize=100。

必须包含策略文件位置、日志输出位置以及三项轮转策略。没有轮转设置会导致磁盘写满，而磁盘写满会使 API 服务器停止。