No impersonation, OIDC pass-through mode - proposal
nickperry opened this issue · 6 comments
Consider the case where an org
a) already has OIDC auth enabled in their clusters.
and
b) wants to use kube-oidc-proxy solely to improve their security posture by preventing non-OIDC auth being used from outside the cluster, e.g. leaked SA tokens and X509 certs.
I wonder for this use-case if there is some value in an option to pass-through OIDC and not use impersonation? In this mode, kube-oidc-proxy's service account would no longer need to be bound to a role with the ability to impersonate users, groups, SAs and scopes.
With the Kube API server now validating the OIDC token itself again and the removal of the impersonation privileges from kube-oidc-proxy, it is harder to ague against putting kube-oidc-proxy in path.
Any implementation would have to consider how to work coherently with #72 (which is almost the antithesis of this proposal).
It's certainly an interesting use case and can see the value in it. Perhaps we create some kind of mode flag to string. Match on default, sa-passthough, oidc-verify or some such.
I'd be interested to at least attempt to implement this later in the week to see what it may look like - after #72 I think.
/assign
/kind feature
/cc @simonswine
I think this is a valid use case. I am not too sure, how scalable that mode notation is. I rather would have feature flags for impersonation, passthrough of service accounts (in a format accepted by the api server).
Wdyt?
Another advantage of this feature would be the users themselves being able to use impersonation again, for example for least privilege.
Cleanup: This has been done
/close
@JoshVanL: Closing this issue.
In response to this:
Cleanup: This has been done
/close
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/test-infra repository.