You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When configuring a projected serviceAccountVolume volume you are usually able to set an expirationSeconds that controls the expiry time of the token e.g
- name: join-sa-tokenprojected:
sources:
- serviceAccountToken:
path: join-sa-token# 600 seconds is the minimum that Kubernetes supports. We# recommend this value is used.expirationSeconds: 600# `example.teleport.sh` must be replaced with the name of# your Teleport cluster.audience: example.teleport.sh
When inspecting a token produced by this configuration within vcluster, we see that instead of producing an expiry of 600 seconds, one of 10 years is produced instead.
This is problematic for two reasons:
It leaves these tokens vulnerable to long-term use if exfiltrated. If someone has configured some sort of federated trust with the Kubernetes cluster, and these tokens are being validated by another service as an OIDC Identity Token, that service will continue to trust the token for 10 years.
Some services (e.g Teleport) enforce a limitation that it will only trust tokens with a short expiry (e.g 30 minutes) to mitigate the above risk.
This issue was reported by a customer of ourselves (Teleport) so I have limited details on the actual cluster configuration.
What did you expect to happen?
The expirationSeconds should be respected and used for the service account tokens expiry:
As noted in the other issue, the implementation was initially done the same way as Kubernetes and has remained the same.
However, replacing the expiration value is more complex than using the value in the projected volumes spec because the syncer makes calls against the vCluster's API server using the token requests API and then stores the resulting tokens in a secret on the host.
Therefore, the syncer would need logic to regenerate the token periodically (if I recall correctly, Kubernetes updates PSATs after 75 or 80% of their expiration time) and then update the secret.
Additionally, there would need to be a mechanism to store and load the token-regeneration dates, crons, or whatever the actual implementation may use, as a syncer restart should maintain this regeneration schedule.
Since you already pointed out this issue's code location, could you create a PR to add the necessary changes?
What happened?
When configuring a projected
serviceAccountVolume
volume you are usually able to set anexpirationSeconds
that controls the expiry time of the token e.gSee https://kubernetes.io/docs/concepts/storage/projected-volumes/#serviceaccounttoken for the Kubernetes side documentation of this.
When inspecting a token produced by this configuration within
vcluster
, we see that instead of producing an expiry of 600 seconds, one of 10 years is produced instead.This is problematic for two reasons:
This issue was reported by a customer of ourselves (Teleport) so I have limited details on the actual cluster configuration.
What did you expect to happen?
The
expirationSeconds
should be respected and used for the service account tokens expiry:How can we reproduce it (as minimally and precisely as possible)?
Add a Projected Service Account token to your PodSpec with a specified
expirationSeconds
and inspect the mounted JWTs expiry.Anything else we need to know?
This looks to be caused by a hardcoded value here:
vcluster/pkg/controllers/resources/pods/translate/translator.go
Line 480 in 0c001e9
Host cluster Kubernetes version
Host cluster Kubernetes distribution
vlcuster version
Vcluster Kubernetes distribution(k3s(default)), k8s, k0s)
OS and Arch
The text was updated successfully, but these errors were encountered: