KEP-3488: Implement secondary authz for ValidatingAdmissionPolicy

[jpbetz]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Implements the Secondary Authz section of CEL for Admission Control.

Example CEL expressions:

authorizer.group('').resource('pods').namespace('default').check('create').allowed()
authorizer.path('/healthz').check('GET').allowed()
authorizer.requestResource.check('my-custom-verb').allowed()

Special notes for your reviewer:

This accounts for a few things missed in the KEP, namely:

• Authz uses resources, not kinds
• A group must be specified for resource authorization, so the builder functions have been adjusted to accomodate
• Authz decisions are tri-state: "allow", "no opinion" and "deny". I've tried to document this. Do we also need a "noOpinion()" function along side "allowed()" and "denied()" ?
• Added a "reason()" function to get the decision reason, which may be useful in messages

Does this PR introduce a user-facing change?

Added authorization check support to the CEL expressions of ValidatingAdmissionPolicy via a `authorizer`
variable with expressions. The new variable provides a builder that allows expressions such `authorizer.group('').resource('pods').check('create').allowed()`.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

• KEP

/sig api-machinery
/priority important-soon

[jpbetz]

/triage accepted

[jpbetz]

/retest

[k8s-triage-robot]

This PR may require API review.

If so, when the changes are ready, complete the pre-review checklist and request an API review.

Status of requested reviews is tracked in the API Review project.

[sftim]

Changelog suggestion:

Added authorization check support to the CEL expressions of ValidatingAdmissionPolicy via a `authorizer`
variable with expressions. The new variable provides a builder that allows expressions such as `authorizer.group('').resource('pods').check('create').allowed()`.

[sftim]

It's not obvious to me how this works. Does this have any interaction with SubjectAccessReview - perhaps via check()?
Alternatively, is this exposing the internals of a particular implementation of the Kubernetes API?

How many HTTP requests to the authz backend does authorizer.group('').resource('pods').check('create').allowed() provoke if webhook authz is enabled? How about for:

authorizer.resource('signers', 'certificates.k8s.io', '*').name(oldObject.spec.signerName).check('approve').allowed() ||
authorizer.resource('signers', 'certificates.k8s.io', '*').name([oldObject.spec.signerName.split('/')[0],'*'].join('/')).check('approve').allowed()

?

You might like to sketch out the docs for this before we merge the code change @jpbetz, to make sure that we know what we need to explain.

[deads2k]

This fell out very nicely. I think the last big question is whether we need to offer a means to specify the username to check the authorizer against. We've used serviceaccounts in the past and doing so using a method .forServiceAccount(namespace, name string) or some-such that restricts specifying any username could encourage patterns that have worked out well in the past without opening up for behavior we want to discourage.

[jpbetz]

You might like to sketch out the docs for this before we merge the code change @jpbetz, to make sure that we know what we need to explain.

Good call @sftim , I've added docs for the Kubernetes CEL libraries, including this one, to kubernetes/website#39642. I've attempted to answer the questions you asked there.

[jpbetz]

@deads2k Feedback addressed and this is ready for another pass when you are ready. Most importantly, service accounts are supported. Thanks for the review!

[jpbetz]

/label api-review

API changes: Adds an authorization variable and CEL functions available to ValidationAdmissionPolicy. Updates api docs to highlight the availability. No API types or fields are changed.

[jpbetz]

/retest

[jpbetz]

Rebased and API review feedback applied

[liggitt]

API bits lgtm, just a few questions on wiring / interfaces / exposed surface area

[liggitt]

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 5036f589367fbbe8f1f1e9803645263ee475e6ca

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jpbetz, liggitt

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:

• api/OWNERS [liggitt]
• pkg/apis/OWNERS [liggitt]
• pkg/generated/openapi/OWNERS [liggitt]
• staging/src/k8s.io/api/OWNERS [liggitt]
• staging/src/k8s.io/apiextensions-apiserver/OWNERS [liggitt]
• staging/src/k8s.io/apiserver/pkg/admission/plugin/cel/OWNERS [jpbetz,liggitt]
• staging/src/k8s.io/apiserver/pkg/admission/plugin/validatingadmissionpolicy/OWNERS [jpbetz,liggitt]
• staging/src/k8s.io/apiserver/pkg/cel/OWNERS [jpbetz,liggitt]
• test/OWNERS [liggitt]

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

[liggitt]

/hold might make sense to squash in review commits?

[liggitt]

/hold cancel
/lgtm

[jpbetz]

Rebased to a reasonable minimum set of commits (keeping codegen separate)