apiserver: add warning about not trusting authz of aggregator

[sttts]

The aggregator does authorization for proxied resources. But aggregated apiservers should not depend on it, but do delegated authorization in addition.

Add warnings that authors of aggregated API servers must not rely on authorization being done by the kube-apiserver.

[sttts]

Any other place we can document this better?

[davidvossel]

The aggregator does authorization for proxied resources. But aggregated apiservers should not depend on it, but do delegated authorization in addition.

If the aggregated apiserver endpoints are trusting user authentication performed by the k8 aggregator, then why can they not also depend on the authorization that the k8s aggregator is currently providing?

[deads2k]

If the aggregated apiserver endpoints are trusting user authentication performed by the k8 aggregator, then why can they not also depend on the authorization that the k8s aggregator is currently providing?

No. The front proxy is an authentication proxy, not an authorization proxy. We document and use it that way and it is common for all apiservers. If we want to introduce the idea of an authorizing front proxy, it may be possible, but that is not what we have created or designed.

@kubernetes/sig-auth-misc

[davidvossel]

If we want to introduce the idea of an authorizing front proxy, it may be possible, but that is not what we have created or designed.

at the moment, my aggregated endpoint is not performing any form of authorization. However I can verify that without the correct RBAC roles, client requests are not forwarded to my endpoint. The client receives a 403 until the correct permissions are in place. So, authorization appears to be taking place.

Just to be clear, we're saying that the authorization performed before the request is forwarded to our aggregated endpoint is not safe to depend on and will be removed? If so, why?

[liggitt]

Just to be clear, we're saying that the authorization performed before the request is forwarded to our aggregated endpoint is not safe to depend on and will be removed? If so, why?

The only guarantee your aggregated API server has from the request header user info is that the proxy is vouching for the fact that that user is making the API request. It makes no guarantee the user is authorized to make that call. (You could place a generic authenticating proxy in front of your API server, verify user info, pass the same user info headers, and your API server would still be expected to perform authorization).

[sttts]

@deads2k any comments about the actual PR contents?

[deads2k]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, sttts

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:

• staging/src/k8s.io/apiserver/OWNERS [deads2k,sttts]

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

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[k8s-github-robot]

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here.