instruction: Create a Dockerfile for configuration
output: ```dockerfile
  from an external service, and then creates Secrets based
  on those short-lived session tokens. Pods running in your cluster can make use of the session tokens,
  and operator ensures they are valid. This separation means that you can run Pods that are unaware of
  the exact mechanisms for issuing and refreshing those session tokens.
  Types of Secret
  When creating a Secret, you can specify its type using the type field of
  the Secret
  resource, or certain equivalent kubectl command line flags (if available).
  The Secret type is used to facilitate programmatic handling of the Secret data.
  Kubernetes provides several built-in types for some common usage scenarios.
  These types vary in terms of the validations performed and the constraints
  Kubernetes imposes on them.
  
  Built-in Type
  Usage
  
  Opaque
  arbitrary user-defined data
  
  kubernetes.io/service-account-token
  ServiceAccount token
  
  kubernetes.io/dockercfg
  serialized ~/.dockercfg file
  
  kubernetes.io/dockerconfigjson
  serialized ~/.docker/config.json file
  
  kubernetes.io/basic-auth
  credentials for basic authentication
  
  kubernetes.io/ssh-auth
  credentials for SSH authentication
  
  kubernetes.io/tls
  data for a TLS client or server
  
  bootstrap.kubernetes.io/token
  bootstrap token data
  
  You can define and use your own Secret type by assigning a non-empty string as the
  type value for a Secret object (an empty string is treated as an Opaque type).
  Kubernetes doesn't impose any constraints on the type name. However, if you
  are using one of the built-in types, you must meet all the requirements defined
  for that type.
  If you are defining a type of Secret that's for public use, follow the convention
  and structure the Secret type to have your domain name before the name, separated
  by a /. For example: cloud-hosting.example.net/cloud-api-credentials.
  Opaque Secrets
  Opaque is the default Secret type if you don't explicitly specify a type in
  a Secret manifest. When you create a Secret using kubectl, you must use the
  generic subcommand to indicate an Opaque Secret type. For example, the
  following command creates an empty Secret of type Opaque:
  kubectl create secret generic empty-secret
  kubectl get secret empty-secret
  The output looks like:
  NAME TYPE DATA AGE
  empty-secret Opaque 0 2m6s
  The DATA column shows the number of data items stored in the Secret.
  In this case, 0 means you have created an empty Secret.
  ServiceAccount token Secrets
  A kubernetes.io/service-account-token type of Secret is used to store a
  token credential that identifies a
  ServiceAccount. This
  is a legacy mechanism that provides long-lived ServiceAccount credentials to
  Pods.
  In Kubernetes v1.22 and later, the recommended approach is to obtain a
  short-lived, automatically rotating ServiceAccount token by using the
  TokenRequest
  API instead. You can get these short-lived tokens using the following methods:
  
  Call the TokenRequest API either directly or by using an API client like
  kubectl. For example, you can use the
  kubectl create token
  command.
  Request a mounted token in a
  projected volume
  in your Pod manifest. Kubernetes creates the token and mounts it in the Pod.
  The token is automatically invalidated when the Pod that it's mounted in is
  deleted. For details, see
  Launch a Pod using service account token projection.
  
  Note: You should only create a ServiceAccount token Secret
  if you can't use the TokenRequest API to obtain a token,
  and the security exposure of persisting a non-expiring token credential
  in a readable API object is acceptable to you. For instructions, see
  Manually create a long-lived API token for a ServiceAccount.
  
  When using this Secret type, you need to ensure that the
  kubernetes.io/service-account.name annotation is set to an existing
  ServiceAccount name. If you are creating both the ServiceAccount and
  the Secret objects, you should create the ServiceAccount object first.
  After the Secret is created, a Kubernetes controller
  fills in some other fields such as the kubernetes.io/service-account.uid annotation, and the
  token key in the data field, which is populated with an authentication token.
  The following example configuration declares a ServiceAccount token Secret:
  
  secret/serviceaccount-token-secret.yaml
  
  apiVersion: v1
  kind: Secret
  metadata:
   name: secret-sa-sample
   annotations:
   kubernetes.io/service-account.name: "sa-name"
  type: kubernetes.io/service-account-token
  data:
   extra: YmFyCg==
  
  After creating the Secret, wait for Kubernetes to populate the token key in the data field.
  See the ServiceAccount
  documentation for more information on how ServiceAccounts work.
  You can also check the automountServiceAccountToken field and the
  serviceAccountName field of the
  Pod
  for information on referencing ServiceAccount credentials
  ```