kubernetes.io/service-account-token doesn't update Service Account Secret

[JJotah]

What happened?

Now in the > 1.24 kubernetes version the creation of the service account is not creating automatically the secret. If you want to create new secret yo need to add something like this

apiVersion: v1
kind: Secret
metadata:
  name: NAMEOFSECRET
  annotations:
    kubernetes.io/service-account.name: NAMEOFSA
type: kubernetes.io/service-account-token

But when you want to retrieve service account secrets is not showing

NAME      SECRETS   AGE
default   0         13d

I want to contribute with this project (because I have more than 3 years working with k8s) I will check the controllers and maybe add new secret token in kubectl cmd to give the option to create the token from command line.

What did you expect to happen?

I want to get secret and show the token assigned in the secret at namespace level

How can we reproduce it (as minimally and precisely as possible)?

kubectl create sa devops

apiVersion: v1
kind: Secret
metadata:
  name: NAMEOFSECRET
  annotations:
    kubernetes.io/service-account.name: NAMEOFSA
type: kubernetes.io/service-account-token

kubectl apply -f devops.yaml
``````yaml
apiVersion: v1
kind: Secret
metadata:
  name: NAMEOFSECRET
  annotations:
    kubernetes.io/service-account.name: NAMEOFSA
type: kubernetes.io/service-account-token

kubectl get secret devops

Anything else we need to know?

No

Kubernetes version

```console $ kubectl version Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.3", Kustomize Version: v4.5.4 Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.1", } ```

Cloud provider

Hetzner

OS version

Ubuntu 22

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

[k8s-ci-robot]

@JJotah: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[JJotah]

/sig auth

[JJotah]

/kind feature

[HarisBalaji]

Hey @JJotah , can I debug this issue? I am interested.

[HarisBalaji]

Can you assign me in this issue?

[liggitt]

Thanks for the issue, this is working as intended. The secrets field in the ServiceAccount API object is only for listing the names of secrets involved in being mounted into pods. Secret-based service account tokens are no longer automounted into pods in 1.21+, and are no longer auto-generated in 1.24+ (when the beta LegacyServiceAccountTokenNoAutoGeneration feature gate is enabled).

Manually created secret-based tokens (described in https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token) are still supported, but do not belong in the secrets field of the ServiceAccount API object.

/close

[k8s-ci-robot]

@liggitt: Closing this issue.

In response to [this](https://github.com/kubernetes/kubernetes/issues/111871#issuecomment-1216826125): >Thanks for the issue, this is working as intended. The `secrets` field in the ServiceAccount API object is *only* for listing the names of secrets involved in being mounted into pods. Secret-based service account tokens are no longer automounted into pods in 1.21+, and are no longer auto-generated in 1.24+ (when the beta LegacyServiceAccountTokenNoAutoGeneration feature gate is enabled). > >Manually created secret-based tokens (described in https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token) are still supported, but do not belong in the `secrets` field of the `ServiceAccount` API object. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[liggitt]

(note that in 1.24+, the kubectl create token exists to make it easy to create a time-bound token using the TokenRequest API)

[JJotah]

Hi, @liggitt I don't get your point regarding don't below, following the doc, in 1.24 when you create the Secret token manually points (in Metadata) to the service Account generating the data in the secret. So for me that means that Secret type ServiceAccount belong to ServiceAccount. Isn't it?

[JJotah]

(note that in 1.24+, the kubectl create token exists to make it easy to create a time-bound token using the TokenRequest API)

Is not the same create token and create secret with type service account with Metadata automatically pointing to the service Account

[liggitt]

I don't get your point regarding don't below, following the doc, in 1.24 when you create the Secret token manually points (in Metadata) to the service Account generating the data in the secret. So for me that means that Secret type ServiceAccount belong to ServiceAccount. Isn't it?

Yes, it is a secret for that service account, but that's not the same as the secrets field in the ServiceAccount API object (which is what kubectl get serviceaccount foo is showing the count of), which is only for secrets mounted into pods.

kubectl get ... only shows data for the object retrieved, not references from other objects

[JJotah]

I don't get your point regarding don't below, following the doc, in 1.24 when you create the Secret token manually points (in Metadata) to the service Account generating the data in the secret. So for me that means that Secret type ServiceAccount belong to ServiceAccount. Isn't it?

Yes, it is a secret for that service account, but that's not the same as the secrets field in the ServiceAccount API object (which is what kubectl get serviceaccount foo is showing the count of), which is only for secrets mounted into pods.

kubectl get ... only shows data for the object retrieved, not references from other objects

HI, OK understood. I was thinking in something like ingress with ingress controller that automatically the ingress discover the address of the ingress controller. So something like that, when anyone wants to create the token manually service account auto discover the secrets referred to the ServiceAccount.