search

jetstack / kube-oidc-proxy

Reverse proxy to authenticate to managed Kubernetes API servers via OIDC.
https://jetstack.io
Apache License 2.0
477 stars 91 forks source link

Support for Impersonation headers #143

Closed EronWright closed 1 year ago

EronWright commented 4 years ago

It might be possible for the proxy to accept the impersonation headers, e.g. to support kubectl --as, with the use of a SubjectAccessReview which would authorize the user to make an impersonated call. Of course, the proxy itself uses impersonation, and in this scenario it would use the supplied user/group (after a successful review).

The key scenario would be to support kubectl --as and --as-group.

Does it seem reasonable that the proxy could do this? Does it parse the incoming request sufficiently to formulate a SubjectAccessReview (ref)?

EronWright commented 4 years ago

I would be happy to work on this, if nobody comes up with a reason that it wouldn't work. Thanks for the input.

JoshVanL commented 4 years ago

Hello @EronWright !

Yes, this has been something I have had on my mind for some time but has been put on the backlog in favor of other things. I don't see anything particularly wrong with this, but it needs to be clear to users what they are enabling with this. The biggest thing for me is that we will loose the audit trail at the API server side since all requests will be purely from the proxy, but with auditing now on the proxy, I see less of an issue. Another note is the proxy will instead of having impersonation RBAC, will probably have ClusterAdmin, This should generally be fine - being able to impersonate gives as much as ClusterAdmin anywho.

We currently expose the flag --disable-impersonation, which when enabled with a new flag --subject-access-review, we should get the behavior you are looking for above. I would expect that the subject access review code being another handler that either accepts or rejects a request.

Fell free to take a stab at it :) If you have any questions don't hesitate to reach out, the kube-oidc-proxy slack channel is probably the best place for ad-hoc comms.

EronWright commented 4 years ago

Sorry to say (in case anyone else would like to work on this), I don't have time to work on this feature.