OPA Gatekeeper 需显式配置ConstraintTemplate的target、精准match范围及正确Rego input结构，否则策略静默失效；Constraint不生效常见于target错误、namespace被exclude、audit匹配条件过严或scope不匹配。
OPA Gatekeeper 不是“开了就能用”的策略开关，它需要明确的约束定义、精准的匹配范围和持续的审计反馈。直接部署后不做配置，Constraint 不生效、Audit 不触发、错误也不报——看起来像没装。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
ConstraintTemplate 定义不匹配 admission.k8s.gatekeeper.sh target 会静默失效
ConstraintTemplate 的 spec.targets 字段必须显式指定 target: "admission.k8s.gatekeeper.sh"，否则 Gatekeeper 不会加载该模板。常见错误是复制 Rego 示例时漏掉这一行，或误写为 admission.k8s.io 等不存在的 target。
- 检查方式：运行
kubectl get constrainttemplates后，用kubectl describe constrainttemplate <name>查看 Events 和 Status.conditions - 若出现
Reason: InvalidTarget或Status: False，大概率是 target 错了 - Rego 中的
input.review.object只在 admission 场景下存在；audit 场景用的是input.current，二者不能混用
Constraint 创建后不拦截 Pod，可能因为 namespace 被 exclude
Gatekeeper 默认跳过kube-system、gatekeeper-system 等系统命名空间，但如果你自定义了 excludedNamespaces 列表，又没把测试用的命名空间加进去，就会导致策略“看起来没生效”。
- 排查命令：
kubectl get constraint -A看 Constraint 是否处于 Active 状态；再查kubectl get k8srequiredimagerepo -A（以实际 Constraint kind 为准）确认是否绑定到目标 namespace - 如果 Constraint 的
spec.match.kinds包含Pod，但spec.match.namespaces为空，它默认作用于所有命名空间（除 excluded 外） - 注意：namespace 必须真实存在，且 Constraint 的
match块中不能写错大小写，比如default≠Default
audit 扫描结果为空，往往是因为资源未被 selector 匹配
Audit 功能不是全量扫描所有资源，而是按 Constraint 中 spec.match 的条件筛选。如果 match 过于严格（例如加了 labelSelector 但目标 Pod 没标签），或用了 scope: Namespaced 却去 audit ClusterRole 这类集群级资源，结果就是 violations: []。
- 查看 audit 状态：
kubectl get constraint -o wide，观察AUDIT STATUS列是否为Active - 检查 audit 日志：
kubectl logs -n gatekeeper-system deploy/gatekeeper-audit，搜索"no matching resources"或"skipping" - 小技巧：临时把
match块删掉（仅测试用），确认 audit 能扫出基础资源，再逐步加回过滤条件
Gatekeeper 的策略执行链条很短：API 请求 → webhook 拦截 → Rego 计算 → 返回 allow/deny。但链条上任意一环配置偏差（target、match、namespace、rego input 结构）都会导致“策略没起作用”——这种失效是静默的，不会抛错，最容易让人误以为工具不可靠。
