instruction: Provide Kubernetes YAML for networking
output: ```yaml
  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 from that Secret.Note:If you view the ServiceAccount using:kubectl get serviceaccount build-robot -o yamlYou can't see the build-robot-secret Secret in the ServiceAccount API objects
  .secrets field
  because that field is only populated with auto-generated Secrets.Add ImagePullSecrets to a service accountFirst, create an imagePullSecret.
  Next, verify it has been created. For example:Create an imagePullSecret, as described in
  Specifying ImagePullSecrets on a Pod.kubectl create secret docker-registry myregistrykey --docker-server=<registry name> \
   --docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
   --docker-email=DUMMY_DOCKER_EMAIL
  Verify it has been created.kubectl get secrets myregistrykey
  The output is similar to this:NAME TYPE DATA AGE
  myregistrykey   kubernetes.io/.dockerconfigjson   1       1d
  Add image pull secret to service accountNext, modify the default service account for the namespace to use this Secret as an imagePullSecret.kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
  You can achieve the same outcome by editing the object manually:kubectl edit serviceaccount/default
  The output of the sa.yaml file is similar to this:Your selected text editor will open with a configuration looking something like this:apiVersion: v1
  kind: ServiceAccount
  metadata:
   creationTimestamp: 2021-07-07T22:02:39Z
   name: default
   namespace: default
   resourceVersion: "243024"
   uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
  Using your editor, delete the line with key resourceVersion, add lines for
  imagePullSecrets: and save it. Leave the uid value set the same as you found it.After you made those changes, the edited ServiceAccount looks something like this:apiVersion: v1
  kind: ServiceAccount
  metadata:
   creationTimestamp: 2021-07-07T22:02:39Z
   name: default
   namespace: default
   uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
  imagePullSecrets:
   - name: myregistrykey
  Verify that imagePullSecrets are set for new PodsNow, when a new Pod is created in the current namespace and using the default
  ServiceAccount, the new Pod has its spec.imagePullSecrets field set automatically:kubectl run nginx --image=<registry name>/nginx --restart=Never
  kubectl get pod nginx -o=jsonpath='{.spec.imagePullSecrets[0].name}{"\n"}'
  The output is:myregistrykey
  ServiceAccount token volume projectionFEATURE STATE:
  Kubernetes v1.20 [stable]Note:To enable and use token request projection, you must specify each of the following
  command line arguments to kube-apiserver:--service-account-issuerdefines the Identifier of the service account token issuer. You can specify the
  --service-account-issuer argument multiple times, this can be useful to enable
  a non-disruptive change of the issuer. When this flag is specified multiple times,
  the first is used to generate tokens and all are used to determine which issuers
  are accepted. You must be running Kubernetes v1.22 or later to be able to specify
  --service-account-issuer multiple times.--service-account-key-filespecifies the path to a file containing PEM-encoded X.509 private or public keys
  (RSA or ECDSA), used to verify ServiceAccount tokens. The specified file can contain
  multiple keys, and the flag can be specified multiple times with different files.
  If specified multiple times, tokens signed by any of the specified keys are considered
  valid by the Kubernetes API server.--service-account-signing-key-filespecifies the path to a file that contains the current private key of the service
  account token issuer. The issuer signs issued ID tokens with this private key.--api-audiences (can be omitted)defines audiences for ServiceAccount tokens. The service account token authenticator
  validates that tokens used against the API are bound to at least one of these audiences.
  If api-audiences is specified multiple times, tokens for any of the specified audiences
  are considered valid by the Kubernetes API server. If you specify the --service-account-issuer
  command line argument but you don't set --api-audiences, the control plane defaults to
  a single element audience list that contains only the issuer URL.The kubelet can also project a ServiceAccount token into a Pod. You can
  specify desired properties of the token, such as the audience and the validity
  duration. These properties are not configurable on the default ServiceAccount
  token. The token will also become invalid against the API when either the Pod
  or the ServiceAccount is deleted.You can configure this behavior for the spec of a Pod using a
  projected volume type called
  ServiceAccountToken.The token from this projected volume is a JSON Web Token (JWT).
  The JSON payload of this token follows a well defined schema - an example payload for a pod bound token:{
   "aud": [ # matches the requested audiences, or the API server's default audiences when none are explicitly requested
   "https://kubernetes.default.svc"
   ],
   "exp": 1731613413,
   "iat": 1700077413,
   "iss": "https://kubernetes.default.svc", # matches the first value passed to the --service-account-issuer flag
   "jti": "ea28ed49-2e11-4280-9ec5-bc3d1d84661a",
   "kubernetes.io": {
   "namespace": "kube-system",
   "node": {
   "name": "127.0.0.1",
   "uid": "58456cb0-dd00-45ed-b797-5578fdceaced"
   },
   "pod": {
   "name": "coredns-69cbfb9798-jv9gn",
   "uid": "778a530c-b3f4-47c0-9cd5-ab018fb64f33"
   },
   "serviceaccount": {
   "name": "coredns",
   "uid": "a087d5a0-e1dd-43ec-93ac-f13d89cd13af"
   },
   "warnafter": 1700081020
   },
   "nbf": 1700077413,
   "sub": "system:serviceaccount:kube-system:coredns"
  }
  Launch a Pod using service account token projectionTo provide a Pod with a token with an audience of vault and a validity duration
  of two hours, you could define a Pod manifest that is similar to:pods/pod-projected-svc-token.yaml
  apiVersion: v1
  kind: Pod
  metadata:
   name: nginx
  spec:
   containers:
   - image: nginx
   name: nginx
   volumeMounts:
   - mountPath: /var/run/secrets/tokens
   name: vault-token
   serviceAccountName: build-robot
   volumes:
   - name: vault-token
   projected:
   sources:
   - serviceAccountToken:
   path: vault-token
   expirationSeconds: 7200
   audience: vault
  Create the Pod:kubectl create -f https://k8s.io/examples/pods/pod-projected-svc-token.yaml
  The kubelet will: request and store the token on behalf of the Pod; make
  the token available to the Pod at a configurable file path; and refresh
  the token as it approaches expiration. The kubelet proactively requests rotation
  for the token if it is older than 80% of its total time-to-live (TTL),
  or if the token is older than 24 hours.The application is responsible for reloading the token when it rotates. It's
  often good enough for the application to load the token on a schedule
  (for example: once every 5 minutes), without tracking the actual expiry time.Service account issuer discoveryFEATURE STATE:
  Kubernetes v1.21 [stable]If you have enabled token projection
  for ServiceAccounts in your cluster, then you can also make use of the discovery
  feature. Kubernetes provides a way for clients to federate as an identity provider,
  so that one or more external systems can act as a relying party.Note:The issuer URL must comply with the
  OIDC Discovery Spec. In
  practice, this means it must use the https scheme, and should serve an OpenID
  provider configuration at {service-account-issuer}/.well-known/openid-configuration.If the URL does not comply, ServiceAccount issuer discovery endpoints are not
  registered or accessible.When enabled, the Kubernetes API server publishes an OpenID Provider
  Configuration document via HTTP. The configuration document is published at
  /.well-known/openid-configuration.
  The OpenID Provider Configuration is sometimes referred to as the discovery document.
  The Kubernetes API server publishes the related
  JSON Web Key Set (JWKS), also via HTTP, at /openid/v1/jwks.Note:The responses served at /.well-known/openid-configuration and
  /openid/v1/jwks are designed to be OIDC compatible, but not strictly OIDC
  compliant. Those documents contain only the parameters necessary to perform
  validation of Kubernetes service account tokens.Clusters that use RBAC include a
  default ClusterRole called system:service-account-issuer-discovery.
  A default ClusterRoleBinding assigns this role to the system:serviceaccounts group,
  which all ServiceAccounts implicitly belong to.
  This allows pods running on the cluster to access the service account discovery document
  via their mounted service account token. Administrators may, additionally, choose to
  bind the role to system:authenticated or system:unauthenticated depending on their
  security requirements and which external systems they intend to federate with.The JWKS response contains public keys that a relying party can use to validate
  the Kubernetes service account tokens. Relying parties first query for the
  OpenID Provider Configuration, and use the jwks_uri field in the response to
  find the JWKS.In many cases, Kubernetes API servers are not available on the public internet,
  but public endpoints that serve cached responses from the API server can be made
  available by users or by service providers. In these cases, it is possible to
  override the jwks_uri in the OpenID Provider Configuration so that it points
  to the public endpoint, rather than the API server's address, by passing the
  --service-account-jwks-uri flag to the API server. Like the issuer URL, the
  JWKS URI is required to use the https scheme.What's nextSee also:Read the Cluster Admin Guide to Service AccountsRead about Authorization in KubernetesRead about Secretsor learn to distribute credentials securely using Secretsbut also bear in mind that using Secrets for authenticating as a ServiceAccount
  is deprecated. The recommended alternative is
  ServiceAccount token volume projection.Read about projected volumes.For background on OIDC discovery, read the
  ServiceAccount signing key retrieval
  Kubernetes Enhancement ProposalRead the OIDC Discovery SpecFeedbackWas this page helpful?Yes
  NoThanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on
  Stack Overflow.
  Open an issue in the GitHub Repository if you want to
  report a problem
  or
  suggest an improvement.Last modified October 31, 2024 at 4:23 PM PST: Update ServiceAccountTokenJTI, ServiceAccountTokenPodNodeInfo, ServiceAccountTokenNodeBindingValidation to stable (2aca56ea10)  Create child page
   Create an issue
   Print entire sectionBefore you beginUse the default service account to access the API serverOpt out of API credential automountingUse more than one ServiceAccountCleanupManually create an API token for a ServiceAccountManually create a long-lived API token for a ServiceAccountAdd ImagePullSecrets to a service accountAdd image pull secret to service accountVerify that imagePullSecrets are set for new PodsServiceAccount token volume projectionLaunch a Pod using service account token projectionService account issuer discoveryWhat's next© 2025 The Kubernetes Authors | Documentation Distributed under CC BY 4.0© 2025 The Linux Foundation ®. ```