Are Kubernetes Validating Admission Policies the end of admission controllers?

The API Machinery Special Interest Group just introduced a long-anticipated feature in Kubernetes: Validating Admission Policies, landing in alpha in version 1.26. This is quite exciting: the more control you can have over what is and isn't allowed to run in your cluster, the better chance you have at securing your software supply chain. Further, putting features in Kubernetes itself prevents ecosystem fragmentation and allows for faster performance, as well as smoother integration without the need for a webhook. But is this a death knell for admission controllers?

‍

In this blog post, we'll see that it’s not, along with:

‍

• How Validating Admission Policies work and what they can do.

• Examples of useful Chainguard Enforce policies that aren’t supported by Validating Admission Policies.

‍

Validating Admission Policies

Now, Kubernetes users can write policies natively, checking resources before admission. This is great news: previously, this required an admission control webhook: the API server would ask your admission controller whether to allow a particular deployment. This came with the attendant complexity of operating an entirely separate service–one more moving part in already-complex Kubernetes clusters. Now, many simple policy checks can happen within the API server, saving a network request for better performance and reliability: for instance, there’s no way for an admission webhook to go down and block all deployments.

‍

The new policies use Google's Common Expression Language (CEL), which is a simple language for writing expressions over structured inputs like Kubernetes resources. It can express boolean operations, access to structured data, string matching and more.

‍

Kubernetes already uses CEL for transition rules and CRD validation. CEL was designed to be fast. This means that Kubernetes can check a policy written in CEL in the hot path of a deployment, without worries that a bad input will cause a long delay.

‍

The documentation gives a number of examples: checking that the number of replicas on a resource is no more than a maxReplicas value, or that a resource has “ok” in its health field. The syntax is familiar to any programmer: object.widgets.exists(w, w.key == 'x' && w.foo < 10), so it will be straightforward to start writing policies of your own.

‍

What can’t Validating Admission Policies do?

By design, CEL is very restricted. This has two benefits: first, a simple language is simple to understand, with no need for troubleshooting. Second, this allows fast evaluation. Both of these are absolutely necessary for something that’s going to run in the hot path in the API server. CEL was a great choice for this feature. But the restricted nature limits the types of policies you can enforce.

‍

Because these policies run inside the API server, they only have access to Kubernetes resources, and furthermore, they can only do ‘peephole’ admission decisions, in that the entire admission decision has to be based on the resource under admission. Because of this, you are unable to do any sort of supply chain security checks (verify image signatures or attestations) because they are properties of the image and not the resource itself. You can’t check for an SBOM with a specific format. CEL doesn’t even have the current time, so a policy to enforce a build horizon is out of the question. And in general, there’s no way to access something like an authorization database. Further, Validating Admission Policies have very few features: there’s no support for custom error/warning messages, or parsing timestamps or other strings, encoding/decoding base64, or sending HTTP requests.

‍

Even if you can express the policy you want, this feature only makes admission decisions. If a deployed workload later goes out of compliance, it will happily chug along without continuous verification. There’s no dashboard with recommendations and automated analysis. All Validating Admission Policies can do is reject resources as they’re submitted.

‍

Conclusion

Validating Admission Policies save anybody who wanted to check relatively simple policies over their Kubernetes resources from needing to run a whole admission controller, and they’re really fast and easy-to-understand, to boot! If you can get away with using them, by all means you should. Validating Admission Policies are a great fit for simple checks, especially for double-checking that a deployment is reasonable. But for security, the lack of support for cryptographic signing and attestations and non-Kubernetes data like SBOMs means that you’ll need to reach for something like Chainguard Enforce, which does continuous admission control and a whole lot more. If you are interested in learning more about Chainguard Enforce, reach out to our team for a demo or a 30-day free trial.