KEP-3488: Implement Enforcement Actions and Audit Annotations

[jpbetz]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Implements the Enforcement Actions and Audit Annotations sections of CEL for Admission Control.

Special notes for your reviewer:

Adding validationActions as a required field is a intentional (alpha stability) breaking change. We want developers setting this explicitly going forward.

Something we missed when writing the KEP: If multiple bindings for a policy match the same resource, I'd decided to have all the unique audit annotation values produced by the auditAnnotations concatenated into a comma-separated value. For simple cases where all the bindings produce the same audit annotation value, this results in that single value being published to the audit event. For cases where bindings produce different values, the values are concatenated into a comma-separated list so no information is lost. Better ideas on how to best combine the values into a single audit annotation value are welcome.

Deviations from the KEP:

• Switched from {policyName}/validation_failure to the validation.policy.admission.k8s.io/validation_failure to adhere better to the conventions of audit annotations.
• Custom audit annotations remain in the form {ValidatingPolicyDefinition name}/{auditAnnotation key}. We had wanted to offer a way to prevent a validating or mutating webhook from producing the exact same audit annotation as a ValidatingPolicyDefinition, but the structure of audit annotation keys makes this awkward because only one / is allowed and there is a length restriction on audit annotation keys.

Does this PR introduce a user-facing change?

Adds auditAnnotations to ValidatingAdmissionPolicy, enabling CEL to be used to add audit annotations to request audit events.
Adds validationActions to ValidatingAdmissionPolicyBinding, enabling validation failures to be handled by any combination of the warn, audit and deny enforcement actions.

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

• KEP

[jpbetz]

/sig api-machinery
/priority important-soon
/api-review

[jpbetz]

/triage accepted

[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.

[jpbetz]

@cici37 Feedback applied, thanks!

[jpbetz]

/retest

[sftim]

We had wanted to offer a way to prevent a validating or mutating webhook from producing the exact same audit annotation as a ValidatingPolicyDefinition, but the structure of audit annotation keys makes this awkward because only one / is allowed and there is a length restriction on audit annotation keys.

Does anything stop me from abusing this to write a well-known annotation key, or to try to fool someone into thinking I did?

[sftim]

I think the question of webhooks and what audit annotations those can write feels like a separate thing. We might still want to think about restricting those too.

[jpbetz]

Rebased and API review feedback applied!

[cici37]

Why to remove this nil check?

[jpbetz]

Now that we have both validations and auditAnnotations, it is possible for one of the calls to Compile to have an empty slice. We could write special case cost to avoid the compile call, but it is less error prone to make the compile calls safe by not returning an error here.

[cici37]

Here is not really a err handling but rather a short circus. I am ok with either since it is nit and not a blocker any way :)

[cici37]

Why this is different than the number in validation?
Also, maybe have a comment to remind keeping it same as it is in validation if it should be the same.
A following up PR might be add this to celconfig file we used in #115747

[jpbetz]

An expressions that concatenate strings will often produce a longer value than the expression, so the expression limit is set at 5kb and the annotation value limits is set at 10k.

[cici37]

Maybe use PolicyName and BindingName here since we only assign name not the entire policy/binding?

[jpbetz]

I was trying to save space since I'm already concerned with the data volume produced by these audit annotation values. It should be clear enough? Let me know if you feel strongly about it.

[cici37]

Just thought we have Policy/Binding all over and it's easily confused in terms of code maintenance.
It is not a merging blocker though :)

[cici37]

Is that possible that evalResult.ExpressionAccessor is nil and evalResult.Error saved the err?
Looks at the code path checks evalResult.ExpressionAccessor.(*AuditAnnotationCondition) before evalResult.Error and the error might be ignored?

[jpbetz]

This is the same order as for validations above. This !ok check is a failure that should never be reached if the code is working as expected (and will go away when we switch to using generics here).

[liggitt]

A couple nits/suggestions, but API types, validation, and docs lgtm.

Once the compile/admission/impl bits are reviewed/approved, tag me back in and I can approve.

[cici37]

Looks like the tests messages need to be updated with the code updates. Couple nits. Overall LGTM :)

[jpbetz]

Feedback applied and commits squashed to minimal set (with codegen separated out)

[cici37]

/lgtm
/approve

/test pull-kubernetes-e2e-kind-ipv6

[k8s-ci-robot]

LGTM label has been added.

Details

Git tree hash: fbbfb21bd33f40a55ccdbfc530ec543351172d47

[liggitt]

/approve
for API changes

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

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

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• api/OWNERS [liggitt]
• pkg/apis/OWNERS [liggitt]
• pkg/generated/openapi/OWNERS [liggitt]
• pkg/registry/admissionregistration/OWNERS [jpbetz,liggitt]
• staging/src/k8s.io/api/OWNERS [liggitt]
• staging/src/k8s.io/apiserver/OWNERS [liggitt]
• staging/src/k8s.io/client-go/applyconfigurations/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