api server: patch operation should use patched object to check admission control

[csrwng]

Currently, patch will check admission control with an empty object and if it passes, then will proceed to update the object with the patch. Admission control plugins don't get a chance to see/validate what is actually going to be updated.

[csrwng]

@lavalamp @deads2k

[liggitt]

@derekwaynecarr

[deads2k]

@smarterclayton @kubernetes/goog-csi @kubernetes/rh-cluster-infra is there a group for API server?

@kubernetes/kube-iam this affects field level authorization.

[deads2k]

I think I want to apply the admission chain twice. Once for patch as-is and once for "update" with the patched object.

This is necessary because admission may mutate the patch itself before its applied, so you can't patch the object ahead of time.

[csrwng]

Why?

[csrwng]

If you check for the patch as is admission control plugins would have to special case objects that are not complete.

[deads2k]

If you check for the patch as is admission control plugins would have to special case objects that are not complete.

Since the patch itself may mutate during the admission process, the "patched" object created at the beginning of the admission change is not guaranteed to be correct, so it would be incorrect for an admission controller to do any work against the "patched" object.

[csrwng]

It may make sense then to have a separate operation (Patch?) for admission control plugins to explicitly check / mutate patches and not special case complete/incomplete objects on update.

[smarterclayton]

@kubernetes/sig-api-machinery

On Mon, Jan 11, 2016 at 10:54 AM, Cesar Wong notifications@github.com
wrote:

It may make sense then to have a separate operation (Patch?) for admission
control plugins to explicitly check / mutate patches and not special case
complete/incomplete objects on update.

—
Reply to this email directly or view it on GitHub
#19479 (comment)
.