Document use of legacy Service Account token mechanism

[sftim]

This is a Feature Request

What would you like to be added
Document how to opt back in to legacy ServiceAccount token autogeneration.

Why is this needed
https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/2799-reduction-of-secret-based-service-account-token describes how we're switching to a new mechanism for ServiceAccount tokens.

If you find that you rely on the stable, Secret-based method for ServiceAccount authentication, you need to disable a feature gate. We should document this; at the moment, those docs are not done for the v1.24 branch.

Comments
/language en
/sig auth
/milestone 1.24

For context, see kubernetes/enhancements#2799

[sftim]

It's not enough to document just the feature gate, because folks who have this need won't want to iterate through every feature gate in the hope that they find one that helps fix the issue they face.

[zshihang]

the idea is to drive users to use manually created legacy tokens instead of auto-generated. #31845

[sftim]

Even though we are recommending a different approach, I'm still concerned that there will be insufficient documentation about how to retain the GA feature (and perhaps also about the implications of doing so).

[sftim]

If we had documentation for the ServiceAccount concept (see #31847) then I'd be less concerned, because in the page about ServiceAccount we could mention the legacy mechanism and why it is deprecated.

[ritazh]

If we had documentation for the ServiceAccount concept (see #31847) then I'd be less concerned, because in the page about ServiceAccount we could mention the legacy mechanism and why it is deprecated.

+1 adding more details

/triage accepted

[ritazh]

If we had documentation for the ServiceAccount concept (see #31847) then I'd be less concerned, because in the page about ServiceAccount we could mention the legacy mechanism and why it is deprecated.

+1 adding more details

/triage accepted

@zshihang can you please follow up on this so we can close this out for v1.24?

[nate-double-u]

This won't be in 1.24, clearing the milestone. This can be added to subsequent milestones if needed.
/milestone clear

[sftim]

/priority backlog

Would be nice to have these docs, but if not then people can use the new recommended mechanism.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[vaibhav2107]

/remove-lifecycle stale

[ritazh]

@shannonxtreme Please make sure this issue is also addressed in #31847

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[timoreimann]

Should this be reopened?

[sftim]

Would be nice to have these docs, but if not then people can use the new recommended mechanism.

I don't think this work is super important. Feel free to explain why it is a higher priority @timoreimann

[timoreimann]

@sftim I was looking for documentation around the three feature gates related to legacy token behavior, and all I could find was the description in the KEP. That seemed insufficient to me because (1) it is more difficult to discover and (2) it is never ultimately clear if the KEP description is still up-to-date or whether it might have been superseded by follow-up work / considerations already.

Please do let me know if you think I missed something.

[sftim]

/reopen
/priority backlog
/remove-lifecycle rotten

PRs are welcome.

[k8s-ci-robot]

@sftim: Reopened this issue.

In response to this:

/reopen
/priority backlog
/remove-lifecycle rotten

PRs are welcome.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[aramase]

@zshihang could you PTAL?

[zshihang]

this is no way to opt back in auto generation of legacy service account token after the GA of LegacyServiceAccountNoAutoGeneration feature.

to manually create legacy tokens, refer to https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount

[zshihang]

@yt2985 sent out a doc change for the other two feature gates about tracking and cleanup of legacy service account token in #43563

[sftim]

this is no way to opt back in auto generation of legacy service account token after the GA of LegacyServiceAccountNoAutoGeneration feature.

to manually create legacy tokens, refer to https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount

LegacyServiceAccountNoAutoGeneration is not a documented feature gate in Kubernetes 1.29 1.28; what did you mean @zhishang?

If you're saying that one day Kubernetes won't let you use the legacy mechanism, that's true. But whilst you can, we should explain how.
If we've already disabled it but forgot to document that, we should really do a backport so that end users can work out what the situation is. Otherwise, they're at risk of a poor UX overall.

[zshihang]

the ask in the issue is

Document how to opt back in to legacy ServiceAccount token autogeneration.

LegacyServiceAccountNoAutoGeneration (no legacy service account autogeneration) is already GA'ed in v1.26 so there is no way to opt back in after v1.26 (that's why the feature gate is gone in v1.28/v1.29). however, we still can create legacy service account token manually and the doc is here https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#create-token.

[sftim]

OK, this is no longer needed and it's stale enough that it's not worth doing for the older releases.

/close not-planned

[k8s-ci-robot]

@sftim: Closing this issue, marking it as "Not Planned".

In response to this:

OK, this is no longer needed and it's stale enough that it's not worth doing.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.