Over the next N releases, we would like to transition the ServiceAccount admission controller to injecting service account token volumes based on the TokenRequest API and volume projection designed here:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/bound-service-account-tokens.md
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/svcacct-token-volume-source.md

I propose we use the feature mechanism, with plenty of lead time and noisy announcements, to phase this change in.

Proposed Plan

This following is pretty close to what the announcement will look like.

With the enablement of a new feature, SecureServiceAccountTokenVolume, we will switch the service account admission control to injecting service account token volumes that use the new TokenRequest API to provision tokens. We will loudly announce a new feature that will be Alpha in 1.13 called SecureServiceAccounTokenVolume.

The new service account token volumes are preferred over the old volumes because:

• Tokens provisioned into the new volumes are only valid for a short TTL and are rotated automatically, minimizing the impact of a token exfiltration.
• Tokens provisioned into the new volumes are bound to the pod, which greatly reduces the difficulty of a forced credential rotation. Operators need only redeploy their application (e.g. trigger a deployment rolling update). This operation is complex to execute without application disruption with the old volumes, and we don’t have any official guidance on the process.
• Tokens provisioned into the new volumes are audience bound to the API server which should dissuade integrators from accepting them as identity proof elsewhere, thus improving the security posture of authentication to the Kubernetes API server.
• Tokens provisioned into the new volumes do not depend on data stored in Kubernetes secrets and are not persisted in any database, reducing the impact and value of a read compromise of the secrets API.
• Tokens provisioned into the new volumes do not depend on data stored in Kubernetes secrets that must be replicated per service account instance which will solve long standing scalability issues with the implementation of service accounts once the migration is complete. See Removing need to have service account tokens in etcd AKA 'dynamic secrets' #48408
• Tokens provisioned into the new volumes are not referable in environment variables via the Downward API.
• Tokens provisioned into the new volumes have stricter file permission. They must be either 0600 or 0640 when using the "fsGroup" feature. They do not allow overrides to more permissive permissions.

The SecureServiceAccounTokenVolume feature will:

*Switch the service account admission controller to using a projected volume (with a token projection) to implement the old service account volume’s filesystem API.

• Make --service-account-issuer a required flag thus requiring that TokenRequest will be enabled.

Users who use the alpha release track to canary what’s coming down the pike will encounter this and will notice that:

• Their API servers won’t start until they add the flags required to enable TokenRequest
• In-cluster clients of the kubernetes apiserver that don’t reload service account tokens will start failing an hour after deployment. They will need to update these clients. (Partial fix in kubernetes/enhancements@d62f9c9)
• PodSecurityPolicies that allowed secret volumes but not projected volumes will no longer be usable with newly created pods that auto-mount service account volumes. They will need to allow projected volumes now.
• Pre-1.11 Kubelets (assuming they also enable alpha features) will no longer run new pods that mount service account volumes.
• Pods running as non root need an fsGroup or they will not have permission to read the token.

We will continue to announce this new behavior each release. We will leave this feature in alpha for a release or more then graduate it to beta and enable it by default. At this point, users will either have to make the changes to upgrade or explicitly disable the beta feature. After a long deprecation, we will promote the feature to GA and remove the ability for clusters to opt out.

Notified Parties

• sig-apimachinery to consult on plan
• sig-arch to consult on plan
• kubernetes-dev to notify of intent to make this change
• kubernetes-announce to notify of intent to make this change

/kind feature
/sig auth
/sig api-machinery

@kubernetes/sig-auth-feature-requests
@kubernetes/sig-api-machinery-feature-requests
@kubernetes/sig-architecture-feature-requests
@liggitt @tallclair @cjcullen @smarterclayton