Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

apiserver: add warning about not trusting authz of aggregator #61349

Merged
merged 1 commit into from Apr 4, 2018

Conversation

Projects
None yet
6 participants
@sttts
Copy link
Contributor

sttts commented Mar 19, 2018

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 sttts force-pushed the sttts:sttts-aggregator-authz branch from 3489d01 to 50b9816 Mar 19, 2018

@sttts

This comment has been minimized.

Copy link
Contributor Author

sttts commented Mar 19, 2018

Any other place we can document this better?

@sttts sttts referenced this pull request Mar 19, 2018

Merged

Subresource Aggregated Apiserver #770

7 of 7 tasks complete
@davidvossel

This comment has been minimized.

Copy link

davidvossel commented Mar 19, 2018

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

This comment has been minimized.

Copy link
Contributor

deads2k commented Mar 19, 2018

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

This comment has been minimized.

Copy link

davidvossel commented Mar 19, 2018

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

This comment has been minimized.

Copy link
Member

liggitt commented Mar 19, 2018

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

This comment has been minimized.

Copy link
Contributor Author

sttts commented Apr 3, 2018

@deads2k any comments about the actual PR contents?

@deads2k

This comment has been minimized.

Copy link
Contributor

deads2k commented Apr 3, 2018

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm label Apr 3, 2018

@k8s-ci-robot

This comment has been minimized.

Copy link
Contributor

k8s-ci-robot commented Apr 3, 2018

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

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

This comment has been minimized.

Copy link
Contributor

k8s-github-robot commented Apr 4, 2018

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

@k8s-github-robot

This comment has been minimized.

Copy link
Contributor

k8s-github-robot commented Apr 4, 2018

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

@k8s-github-robot k8s-github-robot merged commit f5f3d0d into kubernetes:master Apr 4, 2018

13 of 14 checks passed

Submit Queue Required Github CI test is not green: pull-kubernetes-e2e-gce
Details
cla/linuxfoundation sttts authorized
Details
pull-kubernetes-bazel-build Job succeeded.
Details
pull-kubernetes-bazel-test Job succeeded.
Details
pull-kubernetes-cross Skipped
pull-kubernetes-e2e-gce Job succeeded.
Details
pull-kubernetes-e2e-gce-device-plugin-gpu Job succeeded.
Details
pull-kubernetes-e2e-gke Skipped
pull-kubernetes-e2e-kops-aws Job succeeded.
Details
pull-kubernetes-integration Job succeeded.
Details
pull-kubernetes-kubemark-e2e-gce Job succeeded.
Details
pull-kubernetes-node-e2e Job succeeded.
Details
pull-kubernetes-typecheck Job succeeded.
Details
pull-kubernetes-verify Job succeeded.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.