KEP-5917: Add KEP for Authenticator Provided Authorization Constraints

[everettraven]

• One-line PR description: Adds KEP for adding support for authenticator provided authorization constraints

• Issue link: Authenticator Provided Authorization Constraints #5917

[k8s-ci-robot]

Hi @everettraven. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: everettraven
Once this PR has been reviewed and has the lgtm label, please assign micahhausler for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• keps/sig-auth/OWNERS

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

[ahmedtd]

/ok-to-test

[k8s-ci-robot]

@everettraven: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-enhancements-verify	a346858	link	true	/test pull-enhancements-verify

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[ahmedtd]

I think we should build on top of KEP 5681 as much as possible:

• Same condition representation
• Same evaluation model: an authorizer can return conditions, which are then evaluating during the validating admission stage?

Basically, copy the design of KEP 5681, but sub in authenticators instead of authorizers.

If we wanted to think through a concrete case for supporting DPoP from the JWT or service account token authenticators:

1. The authenticator sees that the input JWT carries a cnf.jkt claim.
2. The authenticator gets the DPoP JWT from the DPoP header.
3. The authenticator validates the DPoP JWT against the cnf.jkt claim. If the DPoP JWT does not come from the correct key, the request is rejected.
4. The authenticator checks any statically-checkable properties of the DPoP JWT, like expiration time. If they fail, the request is rejected.
5. The authenticator returns an authentication response, with CEL conditions on the HTTP method and request path.
6. The CEL conditions are evaluated by the conditional authorization machinery during validating admission control. We will need to make sure that the HTTP method and request path are available in the CEL evaluation context.

[everettraven]

Same condition representation

I'm not strongly opinionated on the condition representation format, so if folks strongly prefer CEL expressions as that representation, I'm OK with that. It feels a bit heavy to need to compile CEL expressions and then run them on the fly per request though, so that is why I went with a more RBAC rule-style format for the simple path of something like "This token can only be used to get Pods in Namespace foo".

Same evaluation model: an authorizer can return conditions, which are then evaluating during the validating admission stage?

I think I see two paths here:

1. If we are able to concretely enforce the conditions during the authorization stage we should short-circuit the rest of the request flow
2. If we are not able to concretely enforce the conditions during the authorization stage, we can defer evaluation of those conditions to the conditional authorization logic of KEP 5681

[ahmedtd]

so if folks strongly prefer CEL expressions as that representation

Specifically, I think we should build on exactly the same machinery that's already been / being built for KEP 5681. So that has a CEL (potentially in pre-parsed binary format) for evaluation within kube-apiserver, plus opaque formats that are only understood by the specific authenticator that issued them.

Let's see what others think as well, but I would be wary of introducing a third representation for conditions.

If we are able to concretely enforce the conditions during the authorization stage we should short-circuit the rest of the request flow

I think the gain from this is likely to be small.

There's value in rejecting during authentication (to prevent someone from DoS-ing kube-apiserver with a completely invalid credential), and there's value in rejecting during validating admission control (that's when we have the maximum amount of information about the request available as input to conditions).

Rejecting during authorization saves some compute, but only if someone is spamming you with a valid but downscoped credential that is invalid for the verb/resource they are trying to act upon.

[everettraven]

What about non-resource URLs and resource requests that do not go through admission (like a get/list)?

[ahmedtd]

I think we should do this during validating admission control -- there is no reason a credential like a biscuit, macaron, or future JWT equivalent could not encode restrictions on the request body as well.

"This derived token is only allowed to create Pods that are labeled with foo=bar" or similar.

[everettraven]

"This derived token is only allowed to create Pods that are labeled with foo=bar" or similar.

I agree that this specific statement would be best handled by a conditional authorization check that happens at admission time, but what about "This derived token is only allowed to get Pods in Namespace 'foo'"?

Why should that operation be deferred all the way to validating admission control if we have the information available to use earlier in the request lifecycle to deny it?