instruction: Create a Kubernetes Secret configuration with best practices
output: ```dockerfile
  from that command is a token that you can use to authenticate as that
  ServiceAccount. You can request a specific token duration using the --duration
  command line argument to kubectl create token (the actual duration of the issued
  token might be shorter, or could even be longer).FEATURE STATE:
  Kubernetes v1.33 [stable] (enabled by default: true)Using kubectl v1.31 or later, it is possible to create a service
  account token that is directly bound to a Node:kubectl create token build-robot --bound-object-kind Node --bound-object-name node-001 --bound-object-uid 123...456
  The token will be valid until it expires or either the associated Node or service account are deleted.Note:Versions of Kubernetes before v1.22 automatically created long term credentials for
  accessing the Kubernetes API. This older mechanism was based on creating token Secrets
  that could then be mounted into running Pods. In more recent versions, including
  Kubernetes v1.33, API credentials are obtained directly by using the
  TokenRequest API,
  and are mounted into Pods using a
  projected volume.
  The tokens obtained using this method have bounded lifetimes, and are automatically
  invalidated when the Pod they are mounted into is deleted.You can still manually create a service account token Secret; for example,
  if you need a token that never expires. However, using the
  TokenRequest
  subresource to obtain a token to access the API is recommended instead.Manually create a long-lived API token for a ServiceAccountIf you want to obtain an API token for a ServiceAccount, you create a new Secret
  with a special annotation, kubernetes.io/service-account.name.kubectl apply -f - <<EOF
  apiVersion: v1
  kind: Secret
  metadata:
   name: build-robot-secret
   annotations:
   kubernetes.io/service-account.name: build-robot
  type: kubernetes.io/service-account-token
  EOF
  If you view the Secret using:kubectl get secret/build-robot-secret -o yaml
  you can see that the Secret now contains an API token for the "build-robot" ServiceAccount.Because of the annotation you set, the control plane automatically generates a token for that
  ServiceAccounts, and stores them into the associated Secret. The control plane also cleans up
  tokens for deleted ServiceAccounts.kubectl describe secrets/build-robot-secret
  The output is similar to this:Name: build-robot-secret
  Namespace: default
  Labels: <none>
  Annotations: kubernetes.io/service-account.name: build-robot
   kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da
  
  Type: kubernetes.io/service-account-token
  
  Data
  ====
  ca.crt: 1338 bytes
  namespace: 7 bytes
  token: ...
  Note:The content of token is omitted here.Take care not to display the contents of a kubernetes.io/service-account-token
  Secret somewhere that your terminal / computer screen could be seen by an onlooker.When you delete a ServiceAccount that has an associated Secret, the Kubernetes
  control plane automatically cleans up the long-lived token
  ```