instruction: Create a Kubernetes Pod configuration with best practices
output: ```dockerfile
  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
  ```