KEP: CEL for Admission Control

[Joe Betz]

API Machinery contributors,

A group of Kubernetes contributors have been meeting for the last few months working on a enhancement proposal to leverage CEL for in-process admission control extensibility. We have started to consolidate our ideas into a KEP.

The KEP issue is: https://github.com/kubernetes/enhancements/issues/3488

We are looking for feedback!  There are a couple major unresolved design decisions highlighted in the KEP that could use extra attention, in particular configurability and type safety. General feedback is also much appreciated!

Thanks!

-Joe

[Tim Bannister]

I'm wondering: did we consider making the new ValidatingAdmissionPolicy API be namespaced?

I think it could be useful to be able enforce a rule just for a particular namespace, or possibly to apply it only to namespaces that match a selector.

My further thought: if we used a selector, I think it'd be easy for someone (maybe us, the Kubernetes project) to define a namespaced CRD for to allow namespaces to manage their own admission policy. Accompanying that CRD we'd have a controller watching for that CRD, that then defines a cluster-scoped ValidatingAdmissionPolicy with a selector that could only match objects in the relevant namespace.

That could be a nice way to get an alpha implementation out and still leave room to support namespaces before we graduate the API to stable.

Tim

[Joe Betz]

Hi Tim! We do have a "Namespace scoped policy binding" feature proposed which is in the direction of what you're suggesting but not exactly the same. This proposal allows the "bindings" to be namespace scoped, but doesn't go as far as allowing the policies to be namespace scoped.

If we did support cluster&namespace scoped policy definitions, I think that results in three possible combinations:

| policy definition | policy binding & params CR |

|-------------------|----------------------------|

| cluster scoped    | cluster scoped             |

| cluster scoped    | namespace scoped           |

| namespace scoped  | namespace scoped           |

Does that look right? Any interest in adding an UNRESOLVED to the KEP about this with some rationale? (the kep is merged as "provisional" right now)

-Joe

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/7ae8f8c1-0611-4ce6-8f70-64eb61c33a9en%40googlegroups.com.

[Tim Bannister]

A couple of times I've seen a timely suggestion, after which people have decided to rename their proposed cluster-scoped API from Foo to ClusterFoo, leaving room for a namespaced Foo at some point.

I don't think it applies here, and it sounds like we've thought about it.

I'm not sure my concern is strong enough to warrant an UNRESOLVED, but maybe I'm too cautious - I'm open to being convinced that it's worth adding.

Tim

[Joe Betz]

SG, I'll track this idea. I might do the 'Cluster<kind>" prefixing, we also have some refs between types that I think need to be adjusted to future proof against this. I'll follow up on that.

Thanks!

--

You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/e9d14e52-7193-4de3-a185-e9062d9f10aen%40googlegroups.com.