Closed nickperry closed 4 years ago
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.
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 https://github.com/jetstack/kube-oidc-proxy/pull/72 (which is almost the antithesis of this proposal).