We continue with our discussion on Kubernetes service accounts and their rotation from our earlier post. A service account token is a secret that needs to be guarded. If it is leaked,  it can be misused. This token is available in the volume mount at /var/run/secrets/kubernetes.io/serviceaccount. If should not be injected as a secret or configuration in other pods because doing so makes the tokens harder to rotate.
The mechanism to validate the service account is different from the mechanisms to validate the user accounts. Kubernetes never keeps the users credentials so it is impossible to leak. A token representing the user is short lived so it is useless even when intercepted. The identity asserted in a request and presented by the open id connect holds both user and group information Only a proxy is needed between the identity layer and Kubernetes. The id token is a bearer token and gives access to the bearer without any validation. It's only defense is the short expiry time. The refresh token on the other hand can be used to renew the ID token after its expiry.