4. 策略执行异常场景一：Pod创建被Gatekeeper拒绝——分析AdmissionReview日志

4.1 场景概述

在云原生环境中，Gatekeeper 作为 Kubernetes 的准入控制器（Admission Controller），负责拦截所有 API 请求并根据预定义的 OPA（Open Policy Agent）策略进行校验。当 Pod 创建请求违反约束模板（ConstraintTemplate）或约束（Constraint）时，Gatekeeper 会返回拒绝响应，并记录详细的 AdmissionReview 日志。

本场景模拟一个常见的策略执行异常：用户尝试创建一个未设置 securityContext.runAsNonRoot: true 的 Pod，被 Gatekeeper 拒绝。运维人员需要通过分析 AdmissionReview 日志，定位策略违规的具体原因。

4.2 故障现象与初步排查

用户执行 kubectl apply -f pod.yaml 后，收到类似以下错误：

Error from server (Forbidden): error when creating "pod.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by require-run-as-nonroot] container "nginx" must set securityContext.runAsNonRoot=true

初步排查步骤：

1. 确认 Gatekeeper 组件状态： 检查 gatekeeper-controller-manager Pod 是否正常运行。
2. 检查约束与约束模板： 使用 kubectl get constraints 和 kubectl get constrainttemplates 确认策略已正确部署。
3. 查看 Gatekeeper 日志： 通过 kubectl logs -n gatekeeper-system deployment/gatekeeper-controller-manager 获取原始日志。

4.3 AdmissionReview 日志结构分析

Gatekeeper 的日志通常以 JSON 格式输出，核心是 AdmissionReview 对象。以下是一个典型的拒绝日志片段：

{
  "level": "info",
  "ts": 1712345678.123456,
  "logger": "webhook",
  "msg": "admission review response",
  "hook": "validation.gatekeeper.sh",
  "admission_review": {
    "request": {
      "uid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "kind": {"group": "", "version": "v1", "kind": "Pod"},
      "resource": {"group": "", "version": "v1", "resource": "pods"},
      "name": "my-pod",
      "namespace": "default",
      "operation": "CREATE",
      "object": {
        "apiVersion": "v1",
        "kind": "Pod",
        "metadata": {"name": "my-pod"},
        "spec": {
          "containers": [{
            "name": "nginx",
            "image": "nginx:latest",
            "securityContext": {}
          }]
        }
      }
    },
    "response": {
      "uid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "allowed": false,
      "status": {
        "code": 403,
        "message": "denied by require-run-as-nonroot: container \"nginx\" must set securityContext.runAsNonRoot=true"
      }
    }
  }
}

4.4 日志关键字段解析

4.5 策略执行流程与 AdmissionReview 交互

下图展示了从 Pod 创建请求到 Gatekeeper 返回拒绝响应的完整流程：

4.6 日志分析实战步骤

当面对大量 Gatekeeper 日志时，推荐使用以下方法快速定位问题：

1. 过滤关键日志行： 使用 grep 或 jq 提取包含 "admission review response" 的日志条目。
2. 提取拒绝请求： 过滤 response.allowed == false 的条目。
3. 解析拒绝原因： 从 response.status.message 中提取约束名称和违规详情。
4. 关联请求对象： 查看 request.object 中的 Pod 定义，确认缺失的字段。

4.7 修复与验证

根据日志分析结果，修复 Pod 定义，添加 securityContext.runAsNonRoot: true：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  securityContext:
    runAsNonRoot: true
  containers:
  - name: nginx
    image: nginx:latest
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000

重新应用后，Pod 创建成功，Gatekeeper 日志中对应的新请求将显示 "allowed": true。

4.8 日志分析工具推荐