“Authenticating“ reference page unclear on use of TokenRequest subresource

[jasonjayr]

Regarding the page @ https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens

I got stuck trying to get a token for service account becuase the version of kubernetes I was using was too new. In the example given:

apiVersion: v1
kind: ServiceAccount
metadata:
  # ...
secrets:
- name: jenkins-token-1yvwg

the secrets section was not present in any of my service accounts. According to https://kubernetes.io/docs/concepts/configuration/secret/#service-account-token-secrets the secret needs to be created manually, or the TokenRequest API needs to be used.

[sftim]

/retitle “Authenticating“ reference page unclear on use of TokenRequest subresource
/language en
/sig auth

[sftim]

Similar to #37181

[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

[tengqm]

/remove-lifecycle stale
We definitely need to clarify whatever needs a clear doc.

[enj]

/triage accepted

The docs in v1.25+ correctly avoid referring to the SA's secrets field.

The TokenRequest API went GA in v1.20, so all versions of our docs could be updated to note that. I am unsure what the policy is around keeping old docs versions updated though.