feat: add an opt-in ValidatingAdmissionPolicy analyzer #1764

Is your feature request related to a problem?

Kubernetes ValidatingAdmissionPolicy has been stable since v1.30, but k8sgpt currently has no analyzer for ValidatingAdmissionPolicy or ValidatingAdmissionPolicyBinding resources.

This leaves two high-signal admission-policy misconfigurations outside the current analysis:

• A binding whose spec.policyName references a policy that does not exist. The Kubernetes API documents such a binding as invalid and ignored.
• CEL type-checking problems reported by the API server in status.typeChecking.expressionWarnings, including the affected expression fieldRef and compiler warning.

These problems can make a policy silently ineffective or behave differently from what the cluster administrator intended. The existing ValidatingWebhookConfiguration analyzer does not cover them because admission policies are evaluated directly by the API server rather than through a webhook Service.

References:

• https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/
• https://kubernetes.io/docs/reference/kubernetes-api/admissionregistration/validating-admission-policy-binding-v1/

Describe the solution you'd like

Add a focused analyzer for the built-in admissionregistration.k8s.io/v1 policy resources.

Proposed first slice:

1. List ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding resources through the existing Kubernetes client.
2. Report a binding when spec.policyName does not match an existing policy.
3. Report each entry in a policy's status.typeChecking.expressionWarnings, preserving its fieldRef and warning text in the failure details.
4. Register the analyzer as an additional/opt-in filter so the default core-analyzer behavior remains unchanged, including on clusters older than Kubernetes 1.30.
5. Document the new filter and add fake-client coverage for:
   • a binding referencing a missing policy;
   • a policy with one or more expression warnings;
   • valid policy/binding resources producing no findings;
   • multiple resources being evaluated independently.

Out of scope for the first PR:

• evaluating CEL expressions inside k8sgpt;
• resolving paramKind or paramRef resources;
• MutatingAdmissionPolicy support;
• automated remediation or policy generation.

I would keep the implementation limited to the analyzer registration, analyzer/test files, and the supported-filter documentation unless another integration point is required by the existing analyzer contract.

Describe alternatives you've considered

• Extending the existing ValidatingWebhookConfiguration analyzer. This would mix two different failure domains: webhook receiver health versus API-server CEL policy configuration.
• Treating these resources as generic custom resources. They are built-in, typed Kubernetes APIs with explicit binding and type-checking semantics, so a small typed analyzer can provide more precise and testable diagnostics.
• Starting with only the missing-policy binding check. I am happy to use that as an even smaller first slice if maintainers prefer to discuss how expressionWarnings should be represented before including them.

Additional context

This appears to align with the current roadmap items for analyzer expansion and Kubernetes 1.30+ feature support:

• https://github.com/k8sgpt-ai/k8sgpt/blob/main/ROADMAP.md

The repository currently uses k8s.io/api and k8s.io/client-go v0.32.3, which already expose the v1 policy and binding clients/types. I also searched the existing issues and open pull requests for ValidatingAdmissionPolicy, expressionWarnings, and policy-binding analyzer work and did not find an overlapping proposal.

Would the opt-in analyzer and the two checks above be an acceptable first scope, or would you prefer the binding-reference check to land separately?

Would you be willing to help implement this?

Yes. I would be happy to implement the agreed scope with focused fake-client tests and documentation after maintainers confirm the analyzer boundary.