Kubernetes Validating Admission Policy Changes The Game

[@DevOpsToolkit]

Do you think Kubernetes Validating Admission Policy will replace existing policy engines like Kyverno, Datree, OPA Gatekeeper, and others?

[@arieheinrich3457]

Will not replace, but those tools will add additional layer of rules / customization / reporting that doesnt come baked in k8s. Same as eBPF will not kill for ex. service mesh, the players in the field will just adopt and adjust.

[@peishuli7608]

Thanks for another excellent intro vid Viktor, as always! The new built-in validation resources may present threats to tools like Kyverno, not so much to OPA Gatekeeper, IMHO. As a general purpose "policy engine" (aka, rule engine), OPA comes with advanced rule/policy evaluation capabilities such as forward/reverse chaining to deal with conflicting policies which may be desirable for handling complex scenarios.

[@itstranslations]

Guess Kyverno will die, unfortunately =( Others could rely on idea "universal" policies, and adopt kube-val-adm-policy as an optional engine or something

[@DevOpsToolkit]

My best guess is that kyverno will add the support for the new API by the time VAP goes GA.

[@KnThSelf2ThSelfBTrue]

If you run an org where lots of people are kubectl'ing random things into the cluster, then I guess they're decent (so long as you're using CRDs and deploy manifests transactionally in pipelines) That said, I think it's better to build an IDP. I think a really modern IDP is sort of like a monolithic full-stack app that lets you lock down the cluster and cloud. Because of that, I think it can get away with a lot of client-side logic such as validation. An IDP that was multi-client, single-backend would be interesting. Maybe you could be a hand-tailored IDP vendor for multiple companies? Maybe you want to break up the frontend experience with one frontend for data, one for backend, and one for frontend? Either way, it seems like building a battleship in a world where building a tugboat is seen as already pretty overpowered.

[@aleermapiou2092]

Great video as always Viktor

[@dandogamer]

Just been learning about admission controllers for my CKAD exam and then this pops up!

[@joebowbeer]

I want to be able to validate every PR against the chosen policies in CI, before deployment. This is easy to do in kyverno. Even if using the standard in live clusters, GitOps adherents may still want to use kyverno in CI/CD.

[@chastriq]

If it doesn't already exist, I would imagine someone will just make a tool based on the admission policy controller that can run over static manifests

[@dandogamer]

@@chastriq if we can run the whole of kubernetes in docker then i don't see why this couldn't exist aha

[@ssoriche]

Where do you get the T-shirt?

[@DevOpsToolkit]

I think i bought I on Amazon.

[@joebowbeer]

Beta APIs are now OFF by default? (KEP-3136 implemented in 1.25)

[@DevOpsToolkit]

Yeah. I just reliazed that an hour ago :(

[@cukiris_]

I think that NO. Kyverno and similars will adopt this. Btw, I dont know how k8s folks comes "late" with this features, majors of the tools that exist relative to k8s are to solve k8s deficiencies. The problem come when you enforce the rules and "broke" solutions that solve this problem well done by tools like kyverno.

[@dirien]

I don't see, why they all can't coexist!

[@DevOpsToolkit]

I do think they can all coexist. It's just that I prefer using tools that build on top of a standard than with their own API. A good example is Open Telemetry. I would prefer using observability tool that uses the otel API than one that doesn't. That does not mean that those tools should not have additional features. Ofcourse they should but, from my perspective, those should be on top of otel. I think that the same applies (or will apply) to the Validating Admission Policy. As a side note, I think it's also OK to have a different API (other than the standard) but, in those cases, there must be a good justification (e.g., with the default API we cannot do XYZ and there is no way to extend it).

[@ofir2565]

Simply put - avoiding vendor lock-in ;) It will be interesting to see the adoption and how expressive CEL will be for most use cases

[@DevOpsToolkit]

@ofir2565 I don't think it will replace solutions like kyverno. To begin with, it has only validating policies (no mutating). Also, there are many cases it won't be able to cover. That being said, VAP will be enough for many and, since it will be baked into kubernetes, many will not have to add additional solutions on top.

[@dirien]

@@DevOpsToolkit I think at Rejekts Paris, a talk mentioned that there will be soon mutating policies too! I think even creation of resources via policy.

[@DevOpsToolkit]

@dirien Im guessing it will be a separate project or remove "Validating" from the name 🙂

[@stanrock8015]

Too soon to tell