KEP-3962: Add MutatingAdmissionPolicy as provisional

[jpbetz]

• One-line PR description: Propose using CEL object instantiation + server side apply merges to implement mutating admission for CEL.

• Issue link: Mutating Admission Policies #3962

• Other comments:

  • See https://github.com/jpbetz/celpatch for working examples of CEL to perform mutations. The prototype work done on that repo is being used to inform this KEP.
  • We do not plan to implement this until after ValidatingAdmissionPolicy reaches beta (1.28 hopefully). So I hope to merge this as provisional for now and then transition it to implementable for 1.29.

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jpbetz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• keps/sig-api-machinery/OWNERS [jpbetz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jpbetz]

/sig api-machinery
cc @lavalamp @deads2k @ritazh @maxsmythe @cici37

[irbekrm]

Question: will accessing user info (what is currently admission webhook's user.Info field) ever be possible?
For context, we use mutating webhook to set requester info on an object being created for a later authorization type of check https://github.com/cert-manager/cert-manager/blob/v1.12.0-beta.0/internal/plugin/admission/certificaterequest/identity/certificaterequest_identity.go#L65-L71

[jpbetz]

Yes, it will. For ValidatingAdmissionPolicy we provided access to all the request info available to admission webhooks (including user info) via a "request" variable. We will do the same here. I'll add a note in this KEP.

We also provide an "authorizer" variable that provides access to functions that can be used to perform authz checks.

[kerthcet]

One question here, does it support like injecting a node label to pod and validate the pod's node labels not conflict. E.g.
pod has a label foo:bar, we want to inject a new label like foo:fuz, and we found they're conflicted, then fail into pod creation failure. Thanks.

[jpbetz]

I'm not sure I fully understand the question, but a mutation can add a label, and it can do this conditionally. A validation can be paired with the mutation to reject requests where there was a conflict.

[kerthcet]

My use case is when a pod is located at a specific namespace, I would like to inject some node selectors and node taints, but before injecting, I would like verify whether they're conflict with pod's current node selectors and taints, if conflict, then reject the pod creation.

[jpbetz]

I think I understand. What would be considered a conflict?

[jpbetz]

(I'm going to add a use case for this)

[kerthcet]

Take the nodeSelector for example, we want to inject a foo:bar to pod.nodeSelector but the current pod has a foo:fuz, then they're conflict.

All these ideas come from the exist podNodeSelector and podTolerationRestriction admission plugins.

[ritazh]

Given that the controller knows exactly which fields it's changing and how it should be changed, can this controller do the validation automatically to ensure only the requested fields are updated while others are untouched?

[jpbetz]

Yes, I suggested a possible way to specify this via a ExactAfterReplay enum value for mutationValidation (https://github.com/kubernetes/enhancements/blob/59ea27c348c7a27c7b233730f6851c4b82605917/keps/sig-api-machinery/3962-mutating-admission-policies/README.md#safety).

I will admit I'm not happy with the enum value name ExactAfterReplay, so ideas welcome both on the concept of this validation and of the enum name.

[jpbetz]

A replacement KEP for this is in the works by @cici37. Closing this one.