Closed EronWright closed 1 year 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.
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.
Sorry to say (in case anyone else would like to work on this), I don't have time to work on this feature.
It might be possible for the proxy to accept the impersonation headers, e.g. to support
kubectl --as
, with the use of aSubjectAccessReview
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)?