When using impersonation, the ServiceAccount used by the proxy is privileged. Since this ServiceAccount has no expiration, it could be easily used to compromise a cluster if the cluster owner doesn't know that the token has been compromised. The best way to mitigate this vulnerability is to have short lived tokens that if they are leaked, only have a short window to be used against a cluster. Supporting the TokenRequest API in addition to static ServiceAccount tokens would accomplish this.
Supporting TokenRequest, as of now, requires three pieces:
Knowing where the token is mounted
Checking for when the token expires and getting a new one from the mount
Mounting the cluster's CA certificate - It's not mounted right now as part of the TokenRequest mount the way it is for static ServiceAccount tokens.
1 can be a command line interface (ie --token-mount-point) as can number 3 (ie --cert-mount-point). We implemented this for OpenUnison's impersonation capability and if you'll accept the contribution we'd be happy to contribute the code to do this in kube-oidc-proxy.
When using impersonation, the
ServiceAccount
used by the proxy is privileged. Since thisServiceAccount
has no expiration, it could be easily used to compromise a cluster if the cluster owner doesn't know that the token has been compromised. The best way to mitigate this vulnerability is to have short lived tokens that if they are leaked, only have a short window to be used against a cluster. Supporting theTokenRequest
API in addition to staticServiceAccount
tokens would accomplish this.Supporting
TokenRequest
, as of now, requires three pieces:TokenRequest
mount the way it is for staticServiceAccount
tokens.1 can be a command line interface (ie
--token-mount-point
) as can number 3 (ie--cert-mount-point
). We implemented this for OpenUnison's impersonation capability and if you'll accept the contribution we'd be happy to contribute the code to do this in kube-oidc-proxy.