vault Annotations page title Agent Sidecar Injector Annotations are organized into two sections agent and vault All of the annotations below layout docs This section documents the configurable annotations for the Vault Agent Injector The following are the available annotations for the injector These annotations

Answer:
---
layout: docs
page_title: Agent Sidecar Injector Annotations
description: This section documents the configurable annotations for the Vault Agent Injector.
---

# Annotations

The following are the available annotations for the injector. These annotations
are organized into two sections: agent and vault. All of the annotations below
change the configurations of the Vault Agent containers injected into the pod.

## Agent annotations

Agent annotations change the Vault Agent containers templating configuration. For
example, agent annotations allow users to define what secrets they want, how to render
them, optional commands to run, etc.

- `vault.hashicorp.com/agent-inject` - configures whether injection is explicitly
  enabled or disabled for a pod. This should be set to a `true` or `false` value.
  Defaults to `false`.

- `vault.hashicorp.com/agent-inject-status` - blocks further mutations
  by adding the value `injected` to the pod after a successful mutation.

- `vault.hashicorp.com/agent-configmap` - name of the configuration map where Vault
  Agent configuration file and templates can be found.

- `vault.hashicorp.com/agent-image` - name of the Vault docker image to use. This
  value overrides the default image configured in the injector and is usually
  not needed. Defaults to `hashicorp/vault:1.18.1`.

- `vault.hashicorp.com/agent-init-first` - configures the pod to run the Vault Agent
  init container first if `true` (last if `false`). This is useful when other init
  containers need pre-populated secrets. This should be set to a `true` or `false`
  value. Defaults to `false`.

- `vault.hashicorp.com/agent-inject-command` - configures Vault Agent
  to run a command after the template has been rendered. To map a command to a specific
  secret, use the same unique secret name: `vault.hashicorp.com/agent-inject-command-SECRET-NAME`.
  For example, if a secret annotation `vault.hashicorp.com/agent-inject-secret-foobar`
  is configured, `vault.hashicorp.com/agent-inject-command-foobar` would map a command
  to that secret.

- `vault.hashicorp.com/agent-inject-secret` - configures Vault Agent
  to retrieve the secrets from Vault required by the container. The name of the
  secret is any unique string after `vault.hashicorp.com/agent-inject-secret-`,
  such as `vault.hashicorp.com/agent-inject-secret-foobar`. The value is the path
  in Vault where the secret is located.

- `vault.hashicorp.com/agent-inject-template` - configures the template Vault Agent
  should use for rendering a secret. The name of the template is any
  unique string after `vault.hashicorp.com/agent-inject-template-`, such as
  `vault.hashicorp.com/agent-inject-template-foobar`. This should map to the same
  unique value provided in `vault.hashicorp.com/agent-inject-secret-`. If not provided,
  a default generic template is used.

- `vault.hashicorp.com/agent-template-left-delim` - configures the left delimiter for Vault Agent to
  use when rendering a secret template. The name of the template is any unique string after
  `vault.hashicorp.com/agent-template-left-delim-`, such as
  `vault.hashicorp.com/agent-template-left-delim-foobar`. This should map to the same unique value
  provided in `vault.hashicorp.com/agent-inject-template-`. If not provided, a default left
  delimiter is used as defined by [Vault Agent Template Config](/vault/docs/agent-and-proxy/agent/template#left_delimiter).

- `vault.hashicorp.com/agent-template-right-delim` - configures the right delimiter for Vault Agent
  to use when rendering a secret template. The name of the template is any unique string after
  `vault.hashicorp.com/agent-template-right-delim-`, such as
  `vault.hashicorp.com/agent-template-right-delim-foobar`. This should map to the same unique value
  provided in `vault.hashicorp.com/agent-inject-template-`. If not provided, a default right
  delimiter is used as defined by [Vault Agent Template Config](/vault/docs/agent-and-proxy/agent/template#right_delimiter).

- `vault.hashicorp.com/error-on-missing-key` - configures whether Vault Agent
  should exit with an error when accessing a struct or map field/key that does
  not exist. The name of the secret is the string after
  `vault.hashicorp.com/error-on-missing-key-`, and should map to the same unique
  value provided in `vault.hashicorp.com/agent-inject-secret-`. Defaults to
  `false`. See [Vault Agent Template Config](/vault/docs/agent-and-proxy/agent/template#template-configurations)
  for more details.

- `vault.hashicorp.com/agent-inject-containers` - comma-separated list that specifies in
  which containers the secrets volume should be mounted. If not provided, the secrets
  volume will be mounted in all containers in the pod.

- `vault.hashicorp.com/secret-volume-path` - configures where on the filesystem a secret
  will be rendered. To map a path to a specific secret, use the same unique secret name:
  `vault.hashicorp.com/secret-volume-path-SECRET-NAME`. For example, if a secret annotation
  `vault.hashicorp.com/agent-inject-secret-foobar` is configured,
  `vault.hashicorp.com/secret-volume-path-foobar` would configure where that secret
  is rendered. If no secret name is provided, this sets the default for all rendered
  secrets in the pod.

- `vault.hashicorp.com/agent-inject-file` - configures the filename and path
  in the secrets volume where a Vault secret will be written. This should be used
  with `vault.hashicorp.com/secret-volume-path`, which mounts a memory volume to
  the specified path. If `secret-volume-path` is used, the path can be omitted from
  this value. To map a filename to a specific secret, use the same unique secret name:
  `vault.hashicorp.com/agent-inject-file-SECRET-NAME`. For example, if a secret annotation
  `vault.hashicorp.com/agent-inject-secret-foobar` is configured,
  `vault.hashicorp.com/agent-inject-file-foobar` would configure the filename.

- `vault.hashicorp.com/agent-inject-perms` - configures the permissions of the
  file to create in the secrets volume. The name of the secret is the string
  after "vault.hashicorp.com/agent-inject-perms-", and should map to the same
  unique value provided in "vault.hashicorp.com/agent-inject-secret-". The value
  is the octal permission, for example: `0644`.

- `vault.hashicorp.com/agent-inject-template-file` - configures the path and filename of the
  custom template to use. This should be used with `vault.hashicorp.com/extra-secret`,
  which mounts a Kubernetes secret to `/vault/custom`. To map a template file to a specific secret,
  use the same unique secret name: `vault.hashicorp.com/agent-inject-template-file-SECRET-NAME`.
  For example, if a secret annotation `vault.hashicorp.com/agent-inject-secret-foobar` is configured,
  `vault.hashicorp.com/agent-inject-template-file-foobar` would configure the template file.

- `vault.hashicorp.com/agent-inject-default-template` - configures the default template type for rendering
  secrets if no custom template is defined. Possible values include `map` and `json`. Defaults to `map`.

- `vault.hashicorp.com/template-config-exit-on-retry-failure` - controls whether
  Vault Agent exits after it has exhausted its number of template retry attempts
  due to failures. Defaults to `true`. See [Vault Agent Template
  Config](/vault/docs/agent-and-proxy/agent/template#global-configurations) for more details.

- `vault.hashicorp.com/template-static-secret-render-interval` - If specified,
  configures how often Vault Agent Template should render non-leased secrets such as KV v2.
  See [Vault Agent Template Config](/vault/docs/agent-and-proxy/agent/template#global-configurations) for more details.

- `vault.hashicorp.com/template-max-connections-per-host` - If specified, limits
  the total number of connections that the Vault Agent templating engine can use
  for a particular Vault host. The connection limit includes all connections in the dialing,
  active, and idle states. See [Vault Agent Template Config](/vault/docs/agent-and-proxy/agent/template#global-configurations)
  for more details.

- `vault.hashicorp.com/agent-extra-secret` - mounts Kubernetes secret as a volume at
  `/vault/custom` in the sidecar/init containers. Useful for custom Agent configs with
  auto-auth methods such as approle that require paths to secrets be present.

- `vault.hashicorp.com/agent-inject-token` - configures Vault Agent to share the Vault
  token with other containers in the pod, in a file named `token` in the root of the
  secrets volume (i.e. `/vault/secrets/token`). This is helpful when other containers
  communicate directly with Vault but require auto-authentication provided by Vault
  Agent. This should be set to a `true` or `false` value. Defaults to `false`.

- `vault.hashicorp.com/agent-limits-cpu` - configures the CPU limits on the Vault
  Agent containers. Defaults to `500m`. Setting this to an empty string disables
  CPU limits.

- `vault.hashicorp.com/agent-limits-mem` - configures the memory limits on the Vault
  Agent containers. Defaults to `128Mi`. Setting this to an empty string disables
  memory limits.

- `vault.hashicorp.com/agent-limits-ephemeral` - configures the ephemeral
  storage limit on the Vault Agent containers. Defaults to unset, which
  disables ephemeral storage limits. Also available as a command-line option
  (`-ephemeral-storage-limit`) or environment variable (`AGENT_INJECT_EPHEMERAL_LIMIT`)
  to set the default for all injected Agent containers. **Note:** Pod limits are
  equal to the sum of all container limits. Setting this limit without setting it
  for other containers will also affect the limits of other containers in the pod.
  See [Kubernetes resources documentation][k8s-resources] for more details.

- `vault.hashicorp.com/agent-requests-cpu` - configures the CPU requests on the
  Vault Agent containers. Defaults to `250m`. Setting this to an empty string disables
  CPU requests.

- `vault.hashicorp.com/agent-requests-mem` - configures the memory requests on the
  Vault Agent containers. Defaults to `64Mi`. Setting this to an empty string disables
  memory requests.

- `vault.hashicorp.com/agent-requests-ephemeral` - configures the ephemeral
  storage requests on the Vault Agent Containers. Defaults to unset, which
  disables ephemeral storage requests (and will default to the ephemeral limit
  if set). Also available as a command-line option (`-ephemeral-storage-request`)
  or environment variable (`AGENT_INJECT_EPHEMERAL_REQUEST`) to set the default
  for all injected Agent containers. **Note:** Pod requests are equal to the sum
  of all container requests. Setting this limit without setting it for other
  containers will also affect the requests of other containers in the pod. See
  [Kubernetes resources documentation][k8s-resources] for more details.

- `vault.hashicorp.com/agent-revoke-on-shutdown` - configures whether the sidecar
  will revoke it's own token before shutting down. This setting will only be applied
  to the Vault Agent sidecar container. This should be set to a `true` or `false`
  value. Defaults to `false`.

- `vault.hashicorp.com/agent-revoke-grace` - configures the grace period, in seconds,
  for revoking it's own token before shutting down. This setting will only be applied
  to the Vault Agent sidecar container. Defaults to `5s`.

- `vault.hashicorp.com/agent-pre-populate` - configures whether an init container
  is included to pre-populate the shared memory volume with secrets prior to the
  containers starting. This should be set to a `true` or `false` value. Defaults
  to `true`.

- `vault.hashicorp.com/agent-pre-populate-only` - configures whether an init container
  is the only injected container. If true, no sidecar container will be injected
  at runtime of the pod. Enabling this option is recommended for workloads of
  type `CronJob` or `Job` to ensure a clean pod termination.

- `vault.hashicorp.com/preserve-secret-case` - configures Vault Agent to preserve
  the secret name case when creating the secret files. This should be set to a `true`
  or `false` value. Defaults to `false`.

- `vault.hashicorp.com/agent-run-as-user` - sets the user (uid) to run Vault
  agent as. Also available as a command-line option (`-run-as-user`) or
  environment variable (`AGENT_INJECT_RUN_AS_USER`) for the injector. Defaults
  to 100.

- `vault.hashicorp.com/agent-run-as-group` - sets the group (gid) to run Vault
  agent as. Also available as a command-line option (`-run-as-group`) or
  environment variable (`AGENT_INJECT_RUN_AS_GROUP`) for the injector. Defaults
  to 1000.

- `vault.hashicorp.com/agent-set-security-context` - controls whether
  `SecurityContext` is set in injected containers. Also available as a
  command-line option (`-set-security-context`) or environment variable
  (`AGENT_INJECT_SET_SECURITY_CONTEXT`). Defaults to `true`.

- `vault.hashicorp.com/agent-run-as-same-user` - run the injected Vault agent
  containers as the User (uid) of the first application container in the pod.
  Requires `Spec.Containers[0].SecurityContext.RunAsUser` to be set in the pod
  spec. Also available as a command-line option (`-run-as-same-user`) or
  environment variable (`AGENT_INJECT_RUN_AS_SAME_USER`). Defaults to `false`.

  ~> **Note**: If the first application container in the pod is running as root
  (uid 0), the `run-as-same-user` annotation will fail injection with an error.

- `vault.hashicorp.com/agent-share-process-namespace` - sets
  [shareProcessNamespace] in the Pod spec where Vault Agent is injected.
  Defaults to `false`.

- `vault.hashicorp.com/agent-cache-enable` - configures Vault Agent to enable
  [caching](/vault/docs/agent-and-proxy/agent/caching). In Vault 1.7+ this annotation will also enable
  a Vault Agent persistent cache. This persistent cache will be shared between the init
  and sidecar container to reuse tokens and leases retrieved by the init container.
  Defaults to `false`.

- `vault.hashicorp.com/agent-cache-use-auto-auth-token` - configures Vault Agent cache
  to authenticate on behalf of the requester. Set to `force` to enable. Disabled
  by default.

- `vault.hashicorp.com/agent-cache-listener-port` - configures Vault Agent cache
  listening port. Defaults to `8200`.

- `vault.hashicorp.com/agent-copy-volume-mounts` - copies the mounts from the specified
  container and mounts them to the Vault Agent containers. The service account volume is
  ignored.

- `vault.hashicorp.com/agent-service-account-token-volume-name` - the optional name of a projected volume containing a service account token for use with auto-auth against Vault's Kubernetes auth method. If the volume is mounted to another container in the deployment, the token volume will be mounted to the same location in the vault-agent containers. Otherwise it will be mounted at the default location of `/var/run/secrets/vault.hashicorp.com/serviceaccount/`.

- `vault.hashicorp.com/agent-enable-quit` - enable the [`/agent/v1/quit` endpoint](/vault/docs/agent-and-proxy/agent#quit) on an injected agent. This option defaults to false, and if true will be set on the existing cache listener, or a new localhost listener with a basic cache stanza configured. The [agent-cache-listener-port annotation](/vault/docs/platform/k8s/injector/annotations#vault-hashicorp-com-agent-cache-listener-port) can be used to change the port.

- `vault.hashicorp.com/agent-telemetry` - specifies the [telemetry](/vault/docs/configuration/telemetry) configuration for the
  Vault Agent sidecar. The name of the config is any unique string after
  `vault.hashicorp.com/agent-telemetry-`, such as `vault.hashicorp.com/agent-telemetry-prometheus_retention_time`.
  This annotation can be reused multiple times to configure multiple settings for the agent telemetry.

- `vault.hashicorp.com/go-max-procs` - set the `GOMAXPROCS` environment variable for injected agents

- `vault.hashicorp.com/agent-json-patch` - change the injected agent sidecar container using a [JSON patch](https://jsonpatch.com/) before it is created.
  This can be used to add, remove, or modify any attribute of the container.
  For example, setting this to `[{"op": "replace", "path": "/name", "value": "different-name"}]` will update the agent container's name to be `different-name`
  instead of the default `vault-agent`.

- `vault.hashicorp.com/agent-init-json-patch` - same as `vault.hashicorp.com/agent-json-patch`, except that the JSON patch will be applied to the
  injected init container instead.

## Vault annotations

Vault annotations change how the Vault Agent containers communicate with Vault. For
example, Vault's address, TLS certificates to use, client parameters such as timeouts,
etc.

- `vault.hashicorp.com/auth-config` - configures additional parameters for the configured
  authentication method. The name of the config is any unique string after
  `vault.hashicorp.com/auth-config-`, such as `vault.hashicorp.com/auth-config-role-id-file-path`.
  This annotation can be reused multiple times to configure multiple settings for the authentication
  method. Some authentication methods may require additional secrets and should be mounted via the
  `vault.hashicorp.com/agent-extra-secret` annotation. For a list of valid authentication configurations,
  see the Vault Agent [auto-auth documentation](/vault/docs/agent-and-proxy/autoauth/methods).

- `vault.hashicorp.com/auth-path` - configures the authentication path for the Kubernetes
  auth method. Defaults to `auth/kubernetes`.

- `vault.hashicorp.com/auth-type` - configures the authentication type for Vault Agent.
  Defaults to `kubernetes`. For a list of valid authentication methods, see the Vault Agent
  [auto-auth documentation](/vault/docs/agent-and-proxy/autoauth/methods).

- `vault.hashicorp.com/auth-min-backoff` - set the [min_backoff](/vault/docs/agent-and-proxy/autoauth#min_backoff) option in the auto-auth config. Requires Vault 1.11+.

- `vault.hashicorp.com/auth-max-backoff` - set the [max_backoff](/vault/docs/agent-and-proxy/autoauth#max_backoff) option in the auto-auth config

- `vault.hashicorp.com/agent-auto-auth-exit-on-err` - set the [exit_on_err](/vault/docs/agent-and-proxy/autoauth#exit_on_err) option in the auto-auth config

- `vault.hashicorp.com/ca-cert` - path of the CA certificate used to verify Vault's
  TLS. This can also be set as the default for all injected Agents via the
  `AGENT_INJECT_VAULT_CACERT_BYTES` environment variable which takes a PEM-encoded
  certificate or bundle.

- `vault.hashicorp.com/ca-key` - path of the CA public key used to verify Vault's
  TLS.

- `vault.hashicorp.com/client-cert` - path of the client certificate used when
  communicating with Vault via mTLS.

- `vault.hashicorp.com/client-key` - path of the client public key used when communicating
  with Vault via mTLS.

- `vault.hashicorp.com/client-max-retries` - configures number of Vault Agent retry
  attempts when certain errors are encountered. Defaults to 2, for 3 total attempts.
  Set this to `0` or less to disable retrying. Error codes that are retried are 412
  (client consistency requirement not satisfied) and all 5xx except for 501 (not implemented).

- `vault.hashicorp.com/client-timeout` - configures the request timeout threshold,
  in seconds, of the Vault Agent when communicating with Vault. Defaults to `60s`
  and accepts value types of `60`, `60s` or `1m`.

- `vault.hashicorp.com/log-level` - configures the verbosity of the Vault Agent
  log level. Default is `info`.

- `vault.hashicorp.com/log-format` - configures the log type for Vault Agent. Possible
  values are `standard` and `json`. Default is `standard`.

- `vault.hashicorp.com/namespace` - configures the Vault Enterprise namespace to
  be used when requesting secrets from Vault. Also available as a command-line
  option (`-vault-namespace`) or environment variable
  (`AGENT_INJECT_VAULT_NAMESPACE`) to set the default namespace for all injected
  Agents.

- `vault.hashicorp.com/proxy-address` - configures the HTTP proxy to use when connecting
  to a Vault server.

- `vault.hashicorp.com/role` - configures the Vault role used by the Vault Agent
  auto-auth method. Required when `vault.hashicorp.com/agent-configmap` is not set.

- `vault.hashicorp.com/service` - configures the Vault address for the injected
  Vault Agent to use. This value overrides the default Vault address configured
  in the injector, and may either be the address of a Vault service within the
  same Kubernetes cluster as the injector, or an external Vault URL.

- `vault.hashicorp.com/tls-secret` - name of the Kubernetes secret containing TLS
  Client and CA certificates and keys. This is mounted to `/vault/tls`.

- `vault.hashicorp.com/tls-server-name` - name of the Vault server to verify the
  authenticity of the server when communicating with Vault over TLS.

- `vault.hashicorp.com/tls-skip-verify` - if true, configures the Vault Agent to
  skip verification of Vault's TLS certificate. It's not recommended to set this
  value to true in a production environment.

- `vault.hashicorp.com/agent-disable-idle-connections` - Comma-separated [list
  of Vault Agent features](/vault/docs/agent-and-proxy/agent#disable_idle_connections) where idle
  connections should be disabled. Also available as a command-line option
  (`-disable-idle-connections`) or environment variable
  (`AGENT_INJECT_DISABLE_IDLE_CONNECTIONS`) to set the default for all injected
  Agents.

- `vault.hashicorp.com/agent-disable-keep-alives` - Comma-separated [list of
  Vault Agent features](/vault/docs/agent-and-proxy/agent#disable_keep_alives) where keep-alives
  should be disabled. Also available as a command-line option
  (`-disable-keep-alives`) or environment variable
  (`AGENT_INJECT_DISABLE_KEEP_ALIVES`) to set the default for all injected
  Agents.

[k8s-resources]: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-requests-and-limits-of-pod-and-container
[shareProcessNamespace]: https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/

layout  docs page title  Agent Sidecar Injector Annotations description  This section documents the configurable annotations for the Vault Agent Injector         Annotations  The following are the available annotations for the injector  These annotations are organized into two sections  agent and vault  All of the annotations below change the configurations of the Vault Agent containers injected into the pod      Agent annotations  Agent annotations change the Vault Agent containers templating configuration  For example  agent annotations allow users to define what secrets they want  how to render them  optional commands to run  etc      vault hashicorp com agent inject    configures whether injection is explicitly   enabled or disabled for a pod  This should be set to a  true  or  false  value    Defaults to  false       vault hashicorp com agent inject status    blocks further mutations   by adding the value  injected  to the pod after a successful mutation      vault hashicorp com agent configmap    name of the configuration map where Vault   Agent configuration file and templates can be found      vault hashicorp com agent image    name of the Vault docker image to use  This   value overrides the default image configured in the injector and is usually   not needed  Defaults to  hashicorp vault 1 18 1       vault hashicorp com agent init first    configures the pod to run the Vault Agent   init container first if  true   last if  false    This is useful when other init   containers need pre populated secrets  This should be set to a  true  or  false    value  Defaults to  false       vault hashicorp com agent inject command    configures Vault Agent   to run a command after the template has been rendered  To map a command to a specific   secret  use the same unique secret name   vault hashicorp com agent inject command SECRET NAME     For example  if a secret annotation  vault hashicorp com agent inject secret foobar    is configured   vault hashicorp com agent inject command foobar  would map a command   to that secret      vault hashicorp com agent inject secret    configures Vault Agent   to retrieve the secrets from Vault required by the container  The name of the   secret is any unique string after  vault hashicorp com agent inject secret      such as  vault hashicorp com agent inject secret foobar   The value is the path   in Vault where the secret is located      vault hashicorp com agent inject template    configures the template Vault Agent   should use for rendering a secret  The name of the template is any   unique string after  vault hashicorp com agent inject template    such as    vault hashicorp com agent inject template foobar   This should map to the same   unique value provided in  vault hashicorp com agent inject secret    If not provided    a default generic template is used      vault hashicorp com agent template left delim    configures the left delimiter for Vault Agent to   use when rendering a secret template  The name of the template is any unique string after    vault hashicorp com agent template left delim    such as    vault hashicorp com agent template left delim foobar   This should map to the same unique value   provided in  vault hashicorp com agent inject template    If not provided  a default left   delimiter is used as defined by  Vault Agent Template Config   vault docs agent and proxy agent template left delimiter       vault hashicorp com agent template right delim    configures the right delimiter for Vault Agent   to use when rendering a secret template  The name of the template is any unique string after    vault hashicorp com agent template right delim    such as    vault hashicorp com agent template right delim foobar   This should map to the same unique value   provided in  vault hashicorp com agent inject template    If not provided  a default right   delimiter is used as defined by  Vault Agent Template Config   vault docs agent and proxy agent template right delimiter       vault hashicorp com error on missing key    configures whether Vault Agent   should exit with an error when accessing a struct or map field key that does   not exist  The name of the secret is the string after    vault hashicorp com error on missing key    and should map to the same unique   value provided in  vault hashicorp com agent inject secret    Defaults to    false   See  Vault Agent Template Config   vault docs agent and proxy agent template template configurations    for more details      vault hashicorp com agent inject containers    comma separated list that specifies in   which containers the secrets volume should be mounted  If not provided  the secrets   volume will be mounted in all containers in the pod      vault hashicorp com secret volume path    configures where on the filesystem a secret   will be rendered  To map a path to a specific secret  use the same unique secret name     vault hashicorp com secret volume path SECRET NAME   For example  if a secret annotation    vault hashicorp com agent inject secret foobar  is configured     vault hashicorp com secret volume path foobar  would configure where that secret   is rendered  If no secret name is provided  this sets the default for all rendered   secrets in the pod      vault hashicorp com agent inject file    configures the filename and path   in the secrets volume where a Vault secret will be written  This should be used   with  vault hashicorp com secret volume path   which mounts a memory volume to   the specified path  If  secret volume path  is used  the path can be omitted from   this value  To map a filename to a specific secret  use the same unique secret name     vault hashicorp com agent inject file SECRET NAME   For example  if a secret annotation    vault hashicorp com agent inject secret foobar  is configured     vault hashicorp com agent inject file foobar  would configure the filename      vault hashicorp com agent inject perms    configures the permissions of the   file to create in the secrets volume  The name of the secret is the string   after  vault hashicorp com agent inject perms    and should map to the same   unique value provided in  vault hashicorp com agent inject secret    The value   is the octal permission  for example   0644       vault hashicorp com agent inject template file    configures the path and filename of the   custom template to use  This should be used with  vault hashicorp com extra secret     which mounts a Kubernetes secret to   vault custom   To map a template file to a specific secret    use the same unique secret name   vault hashicorp com agent inject template file SECRET NAME     For example  if a secret annotation  vault hashicorp com agent inject secret foobar  is configured     vault hashicorp com agent inject template file foobar  would configure the template file      vault hashicorp com agent inject default template    configures the default template type for rendering   secrets if no custom template is defined  Possible values include  map  and  json   Defaults to  map       vault hashicorp com template config exit on retry failure    controls whether   Vault Agent exits after it has exhausted its number of template retry attempts   due to failures  Defaults to  true   See  Vault Agent Template   Config   vault docs agent and proxy agent template global configurations  for more details      vault hashicorp com template static secret render interval    If specified    configures how often Vault Agent Template should render non leased secrets such as KV v2    See  Vault Agent Template Config   vault docs agent and proxy agent template global configurations  for more details      vault hashicorp com template max connections per host    If specified  limits   the total number of connections that the Vault Agent templating engine can use   for a particular Vault host  The connection limit includes all connections in the dialing    active  and idle states  See  Vault Agent Template Config   vault docs agent and proxy agent template global configurations    for more details      vault hashicorp com agent extra secret    mounts Kubernetes secret as a volume at     vault custom  in the sidecar init containers  Useful for custom Agent configs with   auto auth methods such as approle that require paths to secrets be present      vault hashicorp com agent inject token    configures Vault Agent to share the Vault   token with other containers in the pod  in a file named  token  in the root of the   secrets volume  i e    vault secrets token    This is helpful when other containers   communicate directly with Vault but require auto authentication provided by Vault   Agent  This should be set to a  true  or  false  value  Defaults to  false       vault hashicorp com agent limits cpu    configures the CPU limits on the Vault   Agent containers  Defaults to  500m   Setting this to an empty string disables   CPU limits      vault hashicorp com agent limits mem    configures the memory limits on the Vault   Agent containers  Defaults to  128Mi   Setting this to an empty string disables   memory limits      vault hashicorp com agent limits ephemeral    configures the ephemeral   storage limit on the Vault Agent containers  Defaults to unset  which   disables ephemeral storage limits  Also available as a command line option      ephemeral storage limit   or environment variable   AGENT INJECT EPHEMERAL LIMIT     to set the default for all injected Agent containers    Note    Pod limits are   equal to the sum of all container limits  Setting this limit without setting it   for other containers will also affect the limits of other containers in the pod    See  Kubernetes resources documentation  k8s resources  for more details      vault hashicorp com agent requests cpu    configures the CPU requests on the   Vault Agent containers  Defaults to  250m   Setting this to an empty string disables   CPU requests      vault hashicorp com agent requests mem    configures the memory requests on the   Vault Agent containers  Defaults to  64Mi   Setting this to an empty string disables   memory requests      vault hashicorp com agent requests ephemeral    configures the ephemeral   storage requests on the Vault Agent Containers  Defaults to unset  which   disables ephemeral storage requests  and will default to the ephemeral limit   if set   Also available as a command line option    ephemeral storage request     or environment variable   AGENT INJECT EPHEMERAL REQUEST   to set the default   for all injected Agent containers    Note    Pod requests are equal to the sum   of all container requests  Setting this limit without setting it for other   containers will also affect the requests of other containers in the pod  See    Kubernetes resources documentation  k8s resources  for more details      vault hashicorp com agent revoke on shutdown    configures whether the sidecar   will revoke it s own token before shutting down  This setting will only be applied   to the Vault Agent sidecar container  This should be set to a  true  or  false    value  Defaults to  false       vault hashicorp com agent revoke grace    configures the grace period  in seconds    for revoking it s own token before shutting down  This setting will only be applied   to the Vault Agent sidecar container  Defaults to  5s       vault hashicorp com agent pre populate    configures whether an init container   is included to pre populate the shared memory volume with secrets prior to the   containers starting  This should be set to a  true  or  false  value  Defaults   to  true       vault hashicorp com agent pre populate only    configures whether an init container   is the only injected container  If true  no sidecar container will be injected   at runtime of the pod  Enabling this option is recommended for workloads of   type  CronJob  or  Job  to ensure a clean pod termination      vault hashicorp com preserve secret case    configures Vault Agent to preserve   the secret name case when creating the secret files  This should be set to a  true    or  false  value  Defaults to  false       vault hashicorp com agent run as user    sets the user  uid  to run Vault   agent as  Also available as a command line option    run as user   or   environment variable   AGENT INJECT RUN AS USER   for the injector  Defaults   to 100      vault hashicorp com agent run as group    sets the group  gid  to run Vault   agent as  Also available as a command line option    run as group   or   environment variable   AGENT INJECT RUN AS GROUP   for the injector  Defaults   to 1000      vault hashicorp com agent set security context    controls whether    SecurityContext  is set in injected containers  Also available as a   command line option    set security context   or environment variable     AGENT INJECT SET SECURITY CONTEXT    Defaults to  true       vault hashicorp com agent run as same user    run the injected Vault agent   containers as the User  uid  of the first application container in the pod    Requires  Spec Containers 0  SecurityContext RunAsUser  to be set in the pod   spec  Also available as a command line option    run as same user   or   environment variable   AGENT INJECT RUN AS SAME USER    Defaults to  false           Note    If the first application container in the pod is running as root    uid 0   the  run as same user  annotation will fail injection with an error      vault hashicorp com agent share process namespace    sets    shareProcessNamespace  in the Pod spec where Vault Agent is injected    Defaults to  false       vault hashicorp com agent cache enable    configures Vault Agent to enable    caching   vault docs agent and proxy agent caching   In Vault 1 7  this annotation will also enable   a Vault Agent persistent cache  This persistent cache will be shared between the init   and sidecar container to reuse tokens and leases retrieved by the init container    Defaults to  false       vault hashicorp com agent cache use auto auth token    configures Vault Agent cache   to authenticate on behalf of the requester  Set to  force  to enable  Disabled   by default      vault hashicorp com agent cache listener port    configures Vault Agent cache   listening port  Defaults to  8200       vault hashicorp com agent copy volume mounts    copies the mounts from the specified   container and mounts them to the Vault Agent containers  The service account volume is   ignored      vault hashicorp com agent service account token volume name    the optional name of a projected volume containing a service account token for use with auto auth against Vault s Kubernetes auth method  If the volume is mounted to another container in the deployment  the token volume will be mounted to the same location in the vault agent containers  Otherwise it will be mounted at the default location of   var run secrets vault hashicorp com serviceaccount        vault hashicorp com agent enable quit    enable the    agent v1 quit  endpoint   vault docs agent and proxy agent quit  on an injected agent  This option defaults to false  and if true will be set on the existing cache listener  or a new localhost listener with a basic cache stanza configured  The  agent cache listener port annotation   vault docs platform k8s injector annotations vault hashicorp com agent cache listener port  can be used to change the port      vault hashicorp com agent telemetry    specifies the  telemetry   vault docs configuration telemetry  configuration for the   Vault Agent sidecar  The name of the config is any unique string after    vault hashicorp com agent telemetry    such as  vault hashicorp com agent telemetry prometheus retention time     This annotation can be reused multiple times to configure multiple settings for the agent telemetry      vault hashicorp com go max procs    set the  GOMAXPROCS  environment variable for injected agents     vault hashicorp com agent json patch    change the injected agent sidecar container using a  JSON patch  https   jsonpatch com   before it is created    This can be used to add  remove  or modify any attribute of the container    For example  setting this to     op    replace    path     name    value    different name     will update the agent container s name to be  different name    instead of the default  vault agent       vault hashicorp com agent init json patch    same as  vault hashicorp com agent json patch   except that the JSON patch will be applied to the   injected init container instead      Vault annotations  Vault annotations change how the Vault Agent containers communicate with Vault  For example  Vault s address  TLS certificates to use  client parameters such as timeouts  etc      vault hashicorp com auth config    configures additional parameters for the configured   authentication method  The name of the config is any unique string after    vault hashicorp com auth config    such as  vault hashicorp com auth config role id file path     This annotation can be reused multiple times to configure multiple settings for the authentication   method  Some authentication methods may require additional secrets and should be mounted via the    vault hashicorp com agent extra secret  annotation  For a list of valid authentication configurations    see the Vault Agent  auto auth documentation   vault docs agent and proxy autoauth methods       vault hashicorp com auth path    configures the authentication path for the Kubernetes   auth method  Defaults to  auth kubernetes       vault hashicorp com auth type    configures the authentication type for Vault Agent    Defaults to  kubernetes   For a list of valid authentication methods  see the Vault Agent    auto auth documentation   vault docs agent and proxy autoauth methods       vault hashicorp com auth min backoff    set the  min backoff   vault docs agent and proxy autoauth min backoff  option in the auto auth config  Requires Vault 1 11       vault hashicorp com auth max backoff    set the  max backoff   vault docs agent and proxy autoauth max backoff  option in the auto auth config     vault hashicorp com agent auto auth exit on err    set the  exit on err   vault docs agent and proxy autoauth exit on err  option in the auto auth config     vault hashicorp com ca cert    path of the CA certificate used to verify Vault s   TLS  This can also be set as the default for all injected Agents via the    AGENT INJECT VAULT CACERT BYTES  environment variable which takes a PEM encoded   certificate or bundle      vault hashicorp com ca key    path of the CA public key used to verify Vault s   TLS      vault hashicorp com client cert    path of the client certificate used when   communicating with Vault via mTLS      vault hashicorp com client key    path of the client public key used when communicating   with Vault via mTLS      vault hashicorp com client max retries    configures number of Vault Agent retry   attempts when certain errors are encountered  Defaults to 2  for 3 total attempts    Set this to  0  or less to disable retrying  Error codes that are retried are 412    client consistency requirement not satisfied  and all 5xx except for 501  not implemented       vault hashicorp com client timeout    configures the request timeout threshold    in seconds  of the Vault Agent when communicating with Vault  Defaults to  60s    and accepts value types of  60    60s  or  1m       vault hashicorp com log level    configures the verbosity of the Vault Agent   log level  Default is  info       vault hashicorp com log format    configures the log type for Vault Agent  Possible   values are  standard  and  json   Default is  standard       vault hashicorp com namespace    configures the Vault Enterprise namespace to   be used when requesting secrets from Vault  Also available as a command line   option    vault namespace   or environment variable     AGENT INJECT VAULT NAMESPACE   to set the default namespace for all injected   Agents      vault hashicorp com proxy address    configures the HTTP proxy to use when connecting   to a Vault server      vault hashicorp com role    configures the Vault role used by the Vault Agent   auto auth method  Required when  vault hashicorp com agent configmap  is not set      vault hashicorp com service    configures the Vault address for the injected   Vault Agent to use  This value overrides the default Vault address configured   in the injector  and may either be the address of a Vault service within the   same Kubernetes cluster as the injector  or an external Vault URL      vault hashicorp com tls secret    name of the Kubernetes secret containing TLS   Client and CA certificates and keys  This is mounted to   vault tls       vault hashicorp com tls server name    name of the Vault server to verify the   authenticity of the server when communicating with Vault over TLS      vault hashicorp com tls skip verify    if true  configures the Vault Agent to   skip verification of Vault s TLS certificate  It s not recommended to set this   value to true in a production environment      vault hashicorp com agent disable idle connections    Comma separated  list   of Vault Agent features   vault docs agent and proxy agent disable idle connections  where idle   connections should be disabled  Also available as a command line option      disable idle connections   or environment variable     AGENT INJECT DISABLE IDLE CONNECTIONS   to set the default for all injected   Agents      vault hashicorp com agent disable keep alives    Comma separated  list of   Vault Agent features   vault docs agent and proxy agent disable keep alives  where keep alives   should be disabled  Also available as a command line option      disable keep alives   or environment variable     AGENT INJECT DISABLE KEEP ALIVES   to set the default for all injected   Agents    k8s resources   https   kubernetes io docs concepts configuration manage resources containers  resource requests and limits of pod and container  shareProcessNamespace   https   kubernetes io docs tasks configure pod container share process namespace


vault Installing the agent injector The Vault Helm chart vault docs platform k8s helm is the recommended way to layout docs install and configure the Agent Injector in Kubernetes The Vault Agent Sidecar Injector can be installed using Vault Helm page title Agent Sidecar Injector Installation

Answer:
---
layout: docs
page_title: Agent Sidecar Injector Installation
description: The Vault Agent Sidecar Injector can be installed using Vault Helm.
---

# Installing the agent injector

The [Vault Helm chart](/vault/docs/platform/k8s/helm) is the recommended way to
install and configure the Agent Injector in Kubernetes.

~> The Vault Agent Injector requires Vault 1.3.1 or greater.

To install a new instance of Vault and the Vault Agent Injector, first add the
Hashicorp helm repository and ensure you have access to the chart:

@include 'helm/repo.mdx'

Then install the chart and enable the injection feature by setting the
`injector.enabled` value to `true`:

```bash
helm install vault hashicorp/vault --set="injector.enabled=true"
```

Upgrades may be performed with `helm upgrade` on an existing install. Please
always run Helm with `--dry-run` before any install or upgrade to verify
changes.

You can see all the available values settings by running `helm inspect values hashicorp/vault` or by reading the [Vault Helm Configuration
Docs](/vault/docs/platform/k8s/helm/configuration). Commonly used values in the Helm
chart include limiting the namespaces the injector runs in, TLS options and
more.

## TLS options

Admission webhook controllers require TLS to run within Kubernetes. The Injector
defaults to supporting TLS 1.2 and above, and supports configuring the minimum
supported TLS version and list of enabled cipher suites. These can be set via
the following environment variables:

| Environment variable             | Description                                                                                |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| `AGENT_INJECT_TLS_MIN_VERSION`   | Minimum supported version of TLS. Defaults to **tls12**. Accepted values are `tls10`, `tls11`, `tls12`, or `tls13`.            |
| `AGENT_INJECT_TLS_CIPHER_SUITES` | Comma-separated list of enabled [cipher suites][tls-suites] for TLS 1.0-1.2. (Cipher suites are not configurable for TLS 1.3.) |

~> **Warning**: TLS 1.1 and lower are generally considered insecure.

These may be set in a Helm chart deployment via the
[injector.extraEnvironmentVars](/vault/docs/platform/k8s/helm/configuration#extraenvironmentvars)
option:

```bash
helm install vault hashicorp/vault \
  --set="injector.extraEnvironmentVars.AGENT_INJECT_TLS_MIN_VERSION=tls13" \
  --set="injector.extraEnvironmentVars.AGENT_INJECT_TLS_CIPHER_SUITES=..."
```

The Vault Agent Injector also supports two TLS management options:

- Auto TLS generation (default)
- Manual TLS

### Auto TLS

By default, the Vault Agent Injector will bootstrap TLS by generating a certificate
authority and creating a certificate/key to be used by the controller. If using
Vault Helm, the chart will automatically create the necessary DNS entries for the
controller's service used to verify the certificate.

### Manual TLS

If desired, users can supply their own TLS certificates, key and certificate authority.
The following is required to configure TLS manually:

- Server certificate/key
- Base64 PEM encoded Certificate Authority bundle

For more information on configuring manual TLS, see the [Vault Helm cert values](/vault/docs/platform/k8s/helm/configuration#certs).

This option may also be used in conjunction with [cert-manager for certificate management](/vault/docs/platform/k8s/helm/examples/injector-tls-cert-manager).

## Multiple replicas and TLS

The Vault Agent Injector can be run with multiple replicas if using [Manual
TLS](#manual-tls) or [cert-manager](/vault/docs/platform/k8s/helm/examples/injector-tls-cert-manager), and as of v0.7.0 multiple replicas are also supported with
[Auto TLS](#auto-tls). The number of replicas is controlled in the Vault Helm
chart by the [injector.replicas
value](/vault/docs/platform/k8s/helm/configuration#replicas).

With Auto TLS and multiple replicas, a leader replica is determined by ownership
of a ConfigMap named `vault-k8s-leader`. Another replica can become the leader
once the current leader replica stops running, and the Kubernetes garbage
collector deletes the ConfigMap. The leader replica is in charge of generating
the CA and patching the webhook caBundle in Kubernetes, and also generating and
distributing the certificate and key to the "followers". The followers read the
certificate and key needed for the webhook service listener from a Kubernetes
Secret, which is updated by the leader when a certificate is near expiration.

With Manual TLS and multiple replicas,
[injector.leaderElector.enabled](/vault/docs/platform/k8s/helm/configuration#enabled-2)
can be set to `false` since leader determination is not necessary in this case.

## Namespace selector

By default, the Vault Agent Injector will process all namespaces in Kubernetes except
the system namespaces `kube-system` and `kube-public`. To limit what namespaces
the injector can work in a namespace selector can be defined to match labels attached
to namespaces.

For more information on configuring namespace selection, see the [Vault Helm namespaceSelector value](/vault/docs/platform/k8s/helm/configuration#namespaceselector).

[tls-suites]: https://golang.org/src/crypto/tls/cipher_suites.go

layout  docs page title  Agent Sidecar Injector Installation description  The Vault Agent Sidecar Injector can be installed using Vault Helm         Installing the agent injector  The  Vault Helm chart   vault docs platform k8s helm  is the recommended way to install and configure the Agent Injector in Kubernetes      The Vault Agent Injector requires Vault 1 3 1 or greater   To install a new instance of Vault and the Vault Agent Injector  first add the Hashicorp helm repository and ensure you have access to the chart    include  helm repo mdx   Then install the chart and enable the injection feature by setting the  injector enabled  value to  true       bash helm install vault hashicorp vault   set  injector enabled true       Upgrades may be performed with  helm upgrade  on an existing install  Please always run Helm with    dry run  before any install or upgrade to verify changes   You can see all the available values settings by running  helm inspect values hashicorp vault  or by reading the  Vault Helm Configuration Docs   vault docs platform k8s helm configuration   Commonly used values in the Helm chart include limiting the namespaces the injector runs in  TLS options and more      TLS options  Admission webhook controllers require TLS to run within Kubernetes  The Injector defaults to supporting TLS 1 2 and above  and supports configuring the minimum supported TLS version and list of enabled cipher suites  These can be set via the following environment variables     Environment variable               Description                                                                                AGENT INJECT TLS MIN VERSION      Minimum supported version of TLS  Defaults to   tls12    Accepted values are  tls10    tls11    tls12   or  tls13                   AGENT INJECT TLS CIPHER SUITES    Comma separated list of enabled  cipher suites  tls suites  for TLS 1 0 1 2   Cipher suites are not configurable for TLS 1 3           Warning    TLS 1 1 and lower are generally considered insecure   These may be set in a Helm chart deployment via the  injector extraEnvironmentVars   vault docs platform k8s helm configuration extraenvironmentvars  option      bash helm install vault hashicorp vault       set  injector extraEnvironmentVars AGENT INJECT TLS MIN VERSION tls13        set  injector extraEnvironmentVars AGENT INJECT TLS CIPHER SUITES           The Vault Agent Injector also supports two TLS management options     Auto TLS generation  default    Manual TLS      Auto TLS  By default  the Vault Agent Injector will bootstrap TLS by generating a certificate authority and creating a certificate key to be used by the controller  If using Vault Helm  the chart will automatically create the necessary DNS entries for the controller s service used to verify the certificate       Manual TLS  If desired  users can supply their own TLS certificates  key and certificate authority  The following is required to configure TLS manually     Server certificate key   Base64 PEM encoded Certificate Authority bundle  For more information on configuring manual TLS  see the  Vault Helm cert values   vault docs platform k8s helm configuration certs    This option may also be used in conjunction with  cert manager for certificate management   vault docs platform k8s helm examples injector tls cert manager       Multiple replicas and TLS  The Vault Agent Injector can be run with multiple replicas if using  Manual TLS   manual tls  or  cert manager   vault docs platform k8s helm examples injector tls cert manager   and as of v0 7 0 multiple replicas are also supported with  Auto TLS   auto tls   The number of replicas is controlled in the Vault Helm chart by the  injector replicas value   vault docs platform k8s helm configuration replicas    With Auto TLS and multiple replicas  a leader replica is determined by ownership of a ConfigMap named  vault k8s leader   Another replica can become the leader once the current leader replica stops running  and the Kubernetes garbage collector deletes the ConfigMap  The leader replica is in charge of generating the CA and patching the webhook caBundle in Kubernetes  and also generating and distributing the certificate and key to the  followers   The followers read the certificate and key needed for the webhook service listener from a Kubernetes Secret  which is updated by the leader when a certificate is near expiration   With Manual TLS and multiple replicas   injector leaderElector enabled   vault docs platform k8s helm configuration enabled 2  can be set to  false  since leader determination is not necessary in this case      Namespace selector  By default  the Vault Agent Injector will process all namespaces in Kubernetes except the system namespaces  kube system  and  kube public   To limit what namespaces the injector can work in a namespace selector can be defined to match labels attached to namespaces   For more information on configuring namespace selection  see the  Vault Helm namespaceSelector value   vault docs platform k8s helm configuration namespaceselector     tls suites   https   golang org src crypto tls cipher suites go


vault Vault lambda extension AWS Lambda lets you run code without provisioning and managing servers page title Vault Lambda Extension layout docs The Vault Lambda Extension allows a Lambda function to read secrets from a Vault deployment

Answer:
---
layout: docs
page_title: Vault Lambda Extension
description: >-
  The Vault Lambda Extension allows a Lambda function to read secrets from a Vault deployment.
---

# Vault lambda extension

AWS Lambda lets you run code without provisioning and managing servers.
The [Vault Lambda Extension](https://github.com/hashicorp/vault-lambda-extension) utilizes the AWS Lambda Extensions API to help your Lambda function read secrets from your Vault deployment.
You can use the [quick-start](https://github.com/hashicorp/vault-lambda-extension/tree/main/quick-start) directory which has an end-to-end example if you would like to try out the extension from scratch.

~> **Note**: If you decide to create one from scratch, be aware that this will create real infrastructure with an associated cost as per AWS' pricing.

## Usage

To use the extension, include one of the following ARNs as a layer in your
Lambda function, depending on your desired architecture.

amd64 (x86_64):
```text
arn:aws:lambda:<your-region>:634166935893:layer:vault-lambda-extension:18
```

arm64:
```text
arn:aws:lambda:<your-region>:634166935893:layer:vault-lambda-extension-arm64:6
```

Where region may be any of `af-south-1`, `ap-east-1`, `ap-northeast-1`,
`ap-northeast-2`, `ap-northeast-3`, `ap-south-1`, `ap-south-2`, `ap-southeast-1`,
`ap-southeast-2`, `ca-central-1`, `eu-central-1`, `eu-north-1`, `eu-south-1`,
`eu-west-1`, `eu-west-2`, `eu-west-3`, `me-south-1`, `sa-east-1`, `us-east-1`,
`us-east-2`, `us-west-1`, `us-west-2`.

The extension authenticates with Vault using [AWS IAM auth](/vault/docs/auth/aws),
and all configuration is supplied via environment variables. There are two methods
to read secrets, which can both be used side-by-side:

- **Recommended**: Make unauthenticated requests to the extension's local proxy
  server at `http://127.0.0.1:8200`, which will add an authentication header and
  proxy to the configured `VAULT_ADDR`. Responses from Vault are returned without
  modification.
- Configure environment variables such as `VAULT_SECRET_PATH` for the extension
  to read a secret and write it to disk.

### Adding the extension to your existing lambda and Vault infrastructure

#### Requirements

- ARN of the role your Lambda runs as
- An instance of Vault accessible from AWS Lambda
- An authenticated `vault` client
- A secret in Vault that you want your Lambda to access, and a policy giving read access to it
- Your Lambda function must use one of the [supported runtimes](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html) for extensions

#### Step 1. configure Vault

Enable the aws auth method.

```shell-session
$ vault auth enable aws
```

Configure the AWS client to use the default options.

```shell-session
$ vault write -force auth/aws/config/client
```

Create a role prefixed with the AWS environment name.

```shell-session
$ vault write auth/aws/role/vault-lambda-role \
    auth_type=iam \
    bound_iam_principal_arn="${YOUR_ARN}" \
    policies="${YOUR_POLICY}" \
    ttl=1h
```

#### Step 2. option a) install the extension for lambda functions packaged in zip archives

If you deploy your Lambda function as a zip file, you can add the extension
to your Lambda layers using the console or [cli](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html#configuration-layers-using):

```text
arn:aws:lambda:<your-region>:634166935893:layer:vault-lambda-extension:11
```

#### Step 2. option b) install the extension for lambda functions packaged in container images

Alternatively, if you deploy your Lambda function as a container image, simply
place the built binary in the `/opt/extensions` directory of your image.

Fetch the binary from
[releases.hashicorp.com](https://releases.hashicorp.com/vault-lambda-extension/).
The following command requires cURL.

```shell-session
$ curl --silent https://releases.hashicorp.com/vault-lambda-extension/0.5.0/vault-lambda-extension_0.5.0_linux_amd64.zip \
  --output vault-lambda-extension.zip
```

Unzip the downloaded binary.

```shell-session
$ unzip vault-lambda-extension.zip
```

Optionally, you can verify the integrity of the downloaded zip using the release
archive checksum verification instructions
[here](https://www.hashicorp.com/security).

Or to build the binary from source. This requires Golang installed. Run from the root of this repository.

```shell-session
$ GOOS=linux GOARCH=amd64 go build -o vault-lambda-extension main.go
```

#### Step 3. configure vault-lambda-extension

Configure the extension using [Lambda environment
variables](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html):

Set the Vault API address.

```shell-session
$ VAULT_ADDR=http://vault.example.com:8200
```

Set the AWS IAM auth mount point (i.e. the path segment after `auth/` from above).

```shell-session
$ VAULT_AUTH_PROVIDER=aws
```

Set the Vault role to authenticate as. Must be configured for the ARN of your
Lambda's role.

```shell-session
$ VAULT_AUTH_ROLE=vault-lambda-role
```

The path to a secret in Vault. Can be static or dynamic. Unless
VAULT_SECRET_FILE is specified, JSON response will be written to
`/tmp/vault/secret.json`.

```shell-session
$ VAULT_SECRET_PATH=secret/lambda-app/token
```

If everything is correctly set up, your Lambda function can then read secret
material from `/tmp/vault/secret.json`. The exact contents of the JSON object
will depend on the secret read, but its schema is the [Secret struct](https://github.com/hashicorp/vault/blob/api/v1.0.4/api/secret.go#L15)
from the Vault API module.

Alternatively, you can send normal Vault API requests over HTTP to the local
proxy at `http://127.0.0.1:8200`, and the extension will add authentication
before forwarding the request. Vault responses will be returned unmodified.
Although local communication is over plain HTTP, the proxy server will use TLS
to communicate with Vault if configured to do so as detailed below.

## Configuration

The extension is configured via [Lambda environment variables](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html).
Most of the [Vault CLI client's environment variables](/vault/docs/commands#environment-variables) are available,
as well as some additional variables to configure auth, which secret(s) to read and
where to write secrets.

| Environment variable              | Description                                                                                | Required | Example value               |
|-----------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------|-----------------------------|
| `VLE_VAULT_ADDR`                  | Vault address to connect to. Takes precedence over `VAULT_ADDR` so that clients of the proxy server can be configured using the standard `VAULT_ADDR`                                                                                | No       | `https://x.x.x.x:8200`      |
| `VAULT_ADDR`                      | Vault address to connect to if `VLE_VAULT_ADDR` is not set. Required if `VLE_VAULT_ADDR` is not set                                                                                | No       | `https://x.x.x.x:8200`      |
| `VAULT_AUTH_PROVIDER`             | Name of the configured AWS IAM auth route on Vault                                                                                | Yes      | `aws`                       |
| `VAULT_AUTH_ROLE`                 | Vault role to authenticate as                                                                                | Yes      | `lambda-app`                |
| `VAULT_IAM_SERVER_ID`             | Value to pass to the Vault server via the [`X-Vault-AWS-IAM-Server-ID` HTTP Header for AWS Authentication](/vault/api-docs/auth/aws#iam_server_id_header_value)                                                                                | No       | `vault.example.com`         |
| `VAULT_SECRET_PATH`               | Secret path to read, written to `/tmp/vault/secret.json` unless `VAULT_SECRET_FILE` is specified                                                                                | No       | `database/creds/lambda-app` |
| `VAULT_SECRET_FILE`               | Path to write the JSON response for `VAULT_SECRET_PATH`                                                                                | No       | `/tmp/db.json`              |
| `VAULT_SECRET_PATH_FOO`           | Additional secret path to read, where FOO can be any name, as long as a matching `VAULT_SECRET_FILE_FOO` is specified                                                                                | No       | `secret/lambda-app/token`   |
| `VAULT_SECRET_FILE_FOO`           | Must exist for any correspondingly named `VAULT_SECRET_PATH_FOO`. Name has no further effect beyond matching to the correct path variable                                                                                | No       | `/tmp/token`                |
| `VAULT_RUN_MODE`                  | Available options are `default`, `proxy`, and `file`. Proxy mode makes requests to the extension's local proxy server. File mode configures the extension to read and write secrets to disk. Default mode uses both file and proxy mode. The default is `default`.                                                    | No       | `default`                   |
| `VAULT_TOKEN_EXPIRY_GRACE_PERIOD` | Period at the end of the proxy server's auth token TTL where it will consider the token expired and attempt to re-authenticate to Vault. Must have a unit and be parseable by `time.Duration`. Defaults to 10s.                                                                                | No       | `1m`                        |
| `VAULT_STS_ENDPOINT_REGION`       | The region of the STS regional endpoint to authenticate with. If the AWS IAM auth mount specified uses a regional STS endpoint, then this needs to match the region of that endpoint. Defaults to using the global endpoint, or the region the Lambda resides in if `AWS_STS_REGIONAL_ENDPOINTS` is set to `regional` | No       | `eu-west-1`                 |

The remaining environment variables are not required, and function exactly as
described in the [Vault Commands (CLI)](/vault/docs/commands#environment-variables) documentation. However,
note that `VAULT_CLIENT_TIMEOUT` cannot extend the timeout beyond the 10s
initialization timeout imposed by the Extensions API when writing files to disk.

| Environment variable          | Description                                                                                | Required | Example value       |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------- |
| `VAULT_CACERT`                | Path to a PEM-encoded CA certificate _file_ on the local disk                                                                                | No       | `/tmp/ca.crt`       |
| `VAULT_CAPATH`                | Path to a _directory_ of PEM-encoded CA certificate files on the local disk                                                                                | No       | `/tmp/certs`        |
| `VAULT_CLIENT_CERT`           | Path to a PEM-encoded client certificate on the local disk                                                                                | No       | `/tmp/client.crt`   |
| `VAULT_CLIENT_KEY`            | Path to an unencrypted, PEM-encoded private key on disk which corresponds to the matching client certificate                                                                    | No       | `/tmp/client.key`   |
| `VAULT_CLIENT_TIMEOUT`        | Timeout for Vault requests. Default value is 60s. Ignored by proxy server. **Any value over 10s will exceed the Extensions API timeout and therefore have no effect**           | No       | `5s`                |
| `VAULT_MAX_RETRIES`           | Maximum number of retries on `5xx` error codes. Defaults to 2. Ignored by proxy server                                                                                | No       | `2`                 |
| `VAULT_SKIP_VERIFY`           | Do not verify Vault's presented certificate before communicating with it. Setting this variable is not recommended and voids Vault's [security model](/vault/docs/internals/security) | No       | `true`              |
| `VAULT_TLS_SERVER_NAME`       | Name to use as the SNI host when connecting via TLS                                                                                | No       | `vault.example.com` |
| `VAULT_RATE_LIMIT`            | Only applies to a single invocation of the extension. See [Vault Commands (CLI)](/vault/docs/commands#environment-variables) documentation for details. Ignored by proxy server       | No       | `10`                |
| `VAULT_NAMESPACE`             | The namespace to use for pre-configured secrets. Ignored by proxy server                                                                                | No       | `education`         |
| `VAULT_DEFAULT_CACHE_TTL`     | The time to live configuration (aka, TTL) of the cache used by proxy server. Must have a unit and be parsable as a time.Duration. Required for caching to be enabled.           | No       | `15m`               |
| `VAULT_DEFAULT_CACHE_ENABLED` | Enable caching for all requests, without needing to set the X-Vault-Cache-Control header for each request. Must be set to a boolean value.                                      | No       | `true`              |
| `VAULT_ASSUMED_ROLE_ARN`      | Valid ARN of an IAM role that can be assumed by the execution role assigned to your Lambda function.                                                                            | No       | `arn:aws:iam::123456789012:role/xaccounts3access`
| `VAULT_LOG_LEVEL`             | Log verbosity level, one of TRACE, DEBUG, INFO, WARN, ERROR, OFF. Defaults to INFO.                                                                                | No       | `DEBUG`

### AWS STS client configuration

In addition to Vault configuration, you can configure certain aspects of the STS
client the extension uses through the usual AWS environment variables. For example,
if your Vault instance's IAM auth is configured to use regional STS endpoints:

```shell-session
$ vault write auth/aws/config/client \
     sts_endpoint="https://sts.eu-west-1.amazonaws.com" \
     sts_region="eu-west-1"
```

Then you may need to configure the extension's STS client to also use the regional
STS endpoint by setting `AWS_STS_REGIONAL_ENDPOINTS=regional`, because both the AWS Golang
SDK and Vault IAM auth method default to using the global endpoint in many regions.
See documentation on [`sts_regional_endpoints`](https://docs.aws.amazon.com/credref/latest/refdocs/setting-global-sts_regional_endpoints.html) for more information.

### Caching

Caching can be configured for the extension's local proxy server so that it does
not forward every HTTP request to Vault. The main consideration behind caching
design is to make caching an explicit opt-in at the request level, so that it is
only enabled for scenarios where caching makes sense without negative impact in
others. To turn on caching, set the environment variable
`VAULT_DEFAULT_CACHE_TTL` to a valid value that is parsable as a time.Duration
in Go, for example, "15m", "1h", "2m3s" or "1h2m3s", depending on application
needs. An invalid or negative value will be treated the same as a missing value,
in which case, caching will not be set up and enabled.

Then requests with HTTP method of "GET", and the HTTP header
`X-Vault-Cache-Control: cache` will be returned directly from the cache if
there's a cache hit. On a cache miss the request will be forwarded to Vault and
the response returned and cached. If the header is set to
`X-Vault-Cache-Control: recache`, the cache lookup will be skipped, and the
request will be forwarded to Vault and the response returned and cached.
Currently, the cache key is a hash of the request URL path, headers, body, and
token.

<Warning title="Nonstandard distributed tracing headers may negate the cache">

  The Vault Lambda Extension cache key includes headers from proxy requests, but
  excludes the standard distributed tracing headers `traceparent` and
  `tracestate` because trace IDs are unique per request and would lead to unique
  hashes for repeated requests.

  Some distributed tracing tools may add nonstandard tracing headers, which can
  also lead to individualized hashes that make repeated requests unique and
  cause cache misses.

</Warning>

Caching may also be enabled for all requests by setting the environment variable
`VAULT_DEFAULT_CACHE_ENABLED` to `true`. Then all requests will be fetched and/or
cached as though the header `X-Vault-Cache-Control: cache` was present. Setting
the header to `nocache` on a request will opt-out of caching entirely in this
configuration. Setting the header to `recache` will skip the cache lookup and
return and cache the response from Vault as described previously.

~> **Warning!** The Vault Lambda Extension's cache is only in-memory
and will not be persisted when the Lambda execution environment shuts down.
In order words, the cache TTL is capped to the duration of the Lambda execution environment.

## Limitations

Secrets written to disk or returned from the proxy server will not be automatically
refreshed when they expire. This is particularly important if you configure the
extension to write secrets to disk, because the extension will only write to disk
once per execution environment, rather than once per function invocation. If you
use [provisioned concurrency](https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html#configuration-concurrency-provisioned) or if your Lambda
is invoked often enough that execution contexts live beyond the lifetime of the
secret, then secrets on disk are likely to become invalid.

In line with [Lambda best practices](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html), we recommend avoiding
writing secrets to disk where possible, and exclusively consuming secrets via
the proxy server. However, the proxy server will still not perform any additional
processing with returned secrets such as automatic lease renewal. The proxy server's
own Vault auth token is the only thing that gets automatically refreshed. It will
synchronously refresh its own token before proxying requests if the token is
expired (including a grace window), and it will attempt to renew its token if the
token is nearly expired but renewable. The proxy will also immediately refresh its token
if the incoming request header `X-Vault-Token-Options: revoke` is present.

<Note title="Not SnapStart compatible">

  The Vault Lambda extension does not currently  work with
  [AWS SnapStart](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html).

</Note>

## Performance impact

AWS Lambda pricing is based on [number of invocations, time of execution and memory
used](https://aws.amazon.com/lambda/pricing/). The following table details some approximate performance
related statistics to help assess the cost impact of this extension. Note that AWS
Lambda allocates [CPU power in proportion to memory](https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html) so results
will vary widely. These benchmarks were run with the minimum 128MB of memory allocated
so aim to give an approximate baseline.

| Metric         | Value                                                                              | Description                                                                                | Derivation                                                                         |
| -------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Layer size     | 8.5MB                                                                              | The size of the unpacked extension binary                                                                                | `ls -la`                                                                           |
| Init latency   | 8.5ms (standard deviation 2.4ms) + one network round trip to authenticate to Vault | Extension initialization time in a new execution environment. Authentication round trip time will be highly deployment-dependent | Instrumented in code                                                               |
| Invoke latency | <1ms                                                                               | The base processing time for each function invocation, assuming no calls to the proxy server                                     | Instrumented in code                                                               |
| Memory impact  | 12MB                                                                               | The marginal impact on "Max Memory Used" when running the extension                                                              | As reported by Lambda when running Hello World function with and without extension |

## Uploading to your own AWS account and region

If you would like to upload the extension as a Lambda layer in your own AWS
account and region, you can do the following:

```shell-session
$ curl --silent https://releases.hashicorp.com/vault-lambda-extension/0.5.0/vault-lambda-extension_0.5.0_linux_amd64.zip \
  --output vault-lambda-extension.zip
```

Set your target AWS region.

```shell-session
$ export REGION="YOUR REGION HERE"
```

Upload the extension as a Lambda layer.

```shell-session
$ aws lambda publish-layer-version \
     --layer-name vault-lambda-extension \
     --zip-file  "fileb://vault-lambda-extension.zip" \
     --region "${REGION}"
```

## Tutorial

For step-by-step instructions, refer to the [Vault AWS Lambda Extension](/vault/tutorials/app-integration/aws-lambda) tutorial for details on how to create an AWS Lambda function and use the Vault Lambda Extension to authenticate with Vault.

layout  docs page title  Vault Lambda Extension description       The Vault Lambda Extension allows a Lambda function to read secrets from a Vault deployment         Vault lambda extension  AWS Lambda lets you run code without provisioning and managing servers  The  Vault Lambda Extension  https   github com hashicorp vault lambda extension  utilizes the AWS Lambda Extensions API to help your Lambda function read secrets from your Vault deployment  You can use the  quick start  https   github com hashicorp vault lambda extension tree main quick start  directory which has an end to end example if you would like to try out the extension from scratch        Note    If you decide to create one from scratch  be aware that this will create real infrastructure with an associated cost as per AWS  pricing      Usage  To use the extension  include one of the following ARNs as a layer in your Lambda function  depending on your desired architecture   amd64  x86 64      text arn aws lambda  your region  634166935893 layer vault lambda extension 18      arm64     text arn aws lambda  your region  634166935893 layer vault lambda extension arm64 6      Where region may be any of  af south 1    ap east 1    ap northeast 1    ap northeast 2    ap northeast 3    ap south 1    ap south 2    ap southeast 1    ap southeast 2    ca central 1    eu central 1    eu north 1    eu south 1    eu west 1    eu west 2    eu west 3    me south 1    sa east 1    us east 1    us east 2    us west 1    us west 2    The extension authenticates with Vault using  AWS IAM auth   vault docs auth aws   and all configuration is supplied via environment variables  There are two methods to read secrets  which can both be used side by side       Recommended    Make unauthenticated requests to the extension s local proxy   server at  http   127 0 0 1 8200   which will add an authentication header and   proxy to the configured  VAULT ADDR   Responses from Vault are returned without   modification    Configure environment variables such as  VAULT SECRET PATH  for the extension   to read a secret and write it to disk       Adding the extension to your existing lambda and Vault infrastructure       Requirements    ARN of the role your Lambda runs as   An instance of Vault accessible from AWS Lambda   An authenticated  vault  client   A secret in Vault that you want your Lambda to access  and a policy giving read access to it   Your Lambda function must use one of the  supported runtimes  https   docs aws amazon com lambda latest dg runtimes extensions api html  for extensions       Step 1  configure Vault  Enable the aws auth method      shell session   vault auth enable aws      Configure the AWS client to use the default options      shell session   vault write  force auth aws config client      Create a role prefixed with the AWS environment name      shell session   vault write auth aws role vault lambda role       auth type iam       bound iam principal arn    YOUR ARN         policies    YOUR POLICY         ttl 1h           Step 2  option a  install the extension for lambda functions packaged in zip archives  If you deploy your Lambda function as a zip file  you can add the extension to your Lambda layers using the console or  cli  https   docs aws amazon com lambda latest dg configuration layers html configuration layers using       text arn aws lambda  your region  634166935893 layer vault lambda extension 11           Step 2  option b  install the extension for lambda functions packaged in container images  Alternatively  if you deploy your Lambda function as a container image  simply place the built binary in the   opt extensions  directory of your image   Fetch the binary from  releases hashicorp com  https   releases hashicorp com vault lambda extension    The following command requires cURL      shell session   curl   silent https   releases hashicorp com vault lambda extension 0 5 0 vault lambda extension 0 5 0 linux amd64 zip       output vault lambda extension zip      Unzip the downloaded binary      shell session   unzip vault lambda extension zip      Optionally  you can verify the integrity of the downloaded zip using the release archive checksum verification instructions  here  https   www hashicorp com security    Or to build the binary from source  This requires Golang installed  Run from the root of this repository      shell session   GOOS linux GOARCH amd64 go build  o vault lambda extension main go           Step 3  configure vault lambda extension  Configure the extension using  Lambda environment variables  https   docs aws amazon com lambda latest dg configuration envvars html    Set the Vault API address      shell session   VAULT ADDR http   vault example com 8200      Set the AWS IAM auth mount point  i e  the path segment after  auth   from above       shell session   VAULT AUTH PROVIDER aws      Set the Vault role to authenticate as  Must be configured for the ARN of your Lambda s role      shell session   VAULT AUTH ROLE vault lambda role      The path to a secret in Vault  Can be static or dynamic  Unless VAULT SECRET FILE is specified  JSON response will be written to   tmp vault secret json       shell session   VAULT SECRET PATH secret lambda app token      If everything is correctly set up  your Lambda function can then read secret material from   tmp vault secret json   The exact contents of the JSON object will depend on the secret read  but its schema is the  Secret struct  https   github com hashicorp vault blob api v1 0 4 api secret go L15  from the Vault API module   Alternatively  you can send normal Vault API requests over HTTP to the local proxy at  http   127 0 0 1 8200   and the extension will add authentication before forwarding the request  Vault responses will be returned unmodified  Although local communication is over plain HTTP  the proxy server will use TLS to communicate with Vault if configured to do so as detailed below      Configuration  The extension is configured via  Lambda environment variables  https   docs aws amazon com lambda latest dg configuration envvars html   Most of the  Vault CLI client s environment variables   vault docs commands environment variables  are available  as well as some additional variables to configure auth  which secret s  to read and where to write secrets     Environment variable                Description                                                                                Required   Example value                                                                                VLE VAULT ADDR                     Vault address to connect to  Takes precedence over  VAULT ADDR  so that clients of the proxy server can be configured using the standard  VAULT ADDR                                                                                No          https   x x x x 8200            VAULT ADDR                         Vault address to connect to if  VLE VAULT ADDR  is not set  Required if  VLE VAULT ADDR  is not set                                                                                No          https   x x x x 8200            VAULT AUTH PROVIDER                Name of the configured AWS IAM auth route on Vault                                                                                Yes         aws                             VAULT AUTH ROLE                    Vault role to authenticate as                                                                                Yes         lambda app                      VAULT IAM SERVER ID                Value to pass to the Vault server via the   X Vault AWS IAM Server ID  HTTP Header for AWS Authentication   vault api docs auth aws iam server id header value                                                                                No          vault example com               VAULT SECRET PATH                  Secret path to read  written to   tmp vault secret json  unless  VAULT SECRET FILE  is specified                                                                                No          database creds lambda app       VAULT SECRET FILE                  Path to write the JSON response for  VAULT SECRET PATH                                                                                No           tmp db json                    VAULT SECRET PATH FOO              Additional secret path to read  where FOO can be any name  as long as a matching  VAULT SECRET FILE FOO  is specified                                                                                No          secret lambda app token         VAULT SECRET FILE FOO              Must exist for any correspondingly named  VAULT SECRET PATH FOO   Name has no further effect beyond matching to the correct path variable                                                                                No           tmp token                      VAULT RUN MODE                     Available options are  default    proxy   and  file   Proxy mode makes requests to the extension s local proxy server  File mode configures the extension to read and write secrets to disk  Default mode uses both file and proxy mode  The default is  default                                                        No          default                         VAULT TOKEN EXPIRY GRACE PERIOD    Period at the end of the proxy server s auth token TTL where it will consider the token expired and attempt to re authenticate to Vault  Must have a unit and be parseable by  time Duration   Defaults to 10s                                                                                No          1m                              VAULT STS ENDPOINT REGION          The region of the STS regional endpoint to authenticate with  If the AWS IAM auth mount specified uses a regional STS endpoint  then this needs to match the region of that endpoint  Defaults to using the global endpoint  or the region the Lambda resides in if  AWS STS REGIONAL ENDPOINTS  is set to  regional    No          eu west 1                     The remaining environment variables are not required  and function exactly as described in the  Vault Commands  CLI    vault docs commands environment variables  documentation  However  note that  VAULT CLIENT TIMEOUT  cannot extend the timeout beyond the 10s initialization timeout imposed by the Extensions API when writing files to disk     Environment variable            Description                                                                                Required   Example value                                                                                VAULT CACERT                   Path to a PEM encoded CA certificate  file  on the local disk                                                                                No           tmp ca crt             VAULT CAPATH                   Path to a  directory  of PEM encoded CA certificate files on the local disk                                                                                No           tmp certs              VAULT CLIENT CERT              Path to a PEM encoded client certificate on the local disk                                                                                No           tmp client crt         VAULT CLIENT KEY               Path to an unencrypted  PEM encoded private key on disk which corresponds to the matching client certificate                                                                      No           tmp client key         VAULT CLIENT TIMEOUT           Timeout for Vault requests  Default value is 60s  Ignored by proxy server    Any value over 10s will exceed the Extensions API timeout and therefore have no effect               No          5s                      VAULT MAX RETRIES              Maximum number of retries on  5xx  error codes  Defaults to 2  Ignored by proxy server                                                                                No          2                       VAULT SKIP VERIFY              Do not verify Vault s presented certificate before communicating with it  Setting this variable is not recommended and voids Vault s  security model   vault docs internals security    No          true                    VAULT TLS SERVER NAME          Name to use as the SNI host when connecting via TLS                                                                                No          vault example com       VAULT RATE LIMIT               Only applies to a single invocation of the extension  See  Vault Commands  CLI    vault docs commands environment variables  documentation for details  Ignored by proxy server         No          10                      VAULT NAMESPACE                The namespace to use for pre configured secrets  Ignored by proxy server                                                                                No          education               VAULT DEFAULT CACHE TTL        The time to live configuration  aka  TTL  of the cache used by proxy server  Must have a unit and be parsable as a time Duration  Required for caching to be enabled              No          15m                     VAULT DEFAULT CACHE ENABLED    Enable caching for all requests  without needing to set the X Vault Cache Control header for each request  Must be set to a boolean value                                         No          true                    VAULT ASSUMED ROLE ARN         Valid ARN of an IAM role that can be assumed by the execution role assigned to your Lambda function                                                                               No          arn aws iam  123456789012 role xaccounts3access     VAULT LOG LEVEL                Log verbosity level  one of TRACE  DEBUG  INFO  WARN  ERROR  OFF  Defaults to INFO                                                                                No          DEBUG       AWS STS client configuration  In addition to Vault configuration  you can configure certain aspects of the STS client the extension uses through the usual AWS environment variables  For example  if your Vault instance s IAM auth is configured to use regional STS endpoints      shell session   vault write auth aws config client        sts endpoint  https   sts eu west 1 amazonaws com         sts region  eu west 1       Then you may need to configure the extension s STS client to also use the regional STS endpoint by setting  AWS STS REGIONAL ENDPOINTS regional   because both the AWS Golang SDK and Vault IAM auth method default to using the global endpoint in many regions  See documentation on   sts regional endpoints   https   docs aws amazon com credref latest refdocs setting global sts regional endpoints html  for more information       Caching  Caching can be configured for the extension s local proxy server so that it does not forward every HTTP request to Vault  The main consideration behind caching design is to make caching an explicit opt in at the request level  so that it is only enabled for scenarios where caching makes sense without negative impact in others  To turn on caching  set the environment variable  VAULT DEFAULT CACHE TTL  to a valid value that is parsable as a time Duration in Go  for example   15m    1h    2m3s  or  1h2m3s   depending on application needs  An invalid or negative value will be treated the same as a missing value  in which case  caching will not be set up and enabled   Then requests with HTTP method of  GET   and the HTTP header  X Vault Cache Control  cache  will be returned directly from the cache if there s a cache hit  On a cache miss the request will be forwarded to Vault and the response returned and cached  If the header is set to  X Vault Cache Control  recache   the cache lookup will be skipped  and the request will be forwarded to Vault and the response returned and cached  Currently  the cache key is a hash of the request URL path  headers  body  and token    Warning title  Nonstandard distributed tracing headers may negate the cache      The Vault Lambda Extension cache key includes headers from proxy requests  but    excludes the standard distributed tracing headers  traceparent  and    tracestate  because trace IDs are unique per request and would lead to unique   hashes for repeated requests       Some distributed tracing tools may add nonstandard tracing headers  which can    also lead to individualized hashes that make repeated requests unique and    cause cache misses     Warning   Caching may also be enabled for all requests by setting the environment variable  VAULT DEFAULT CACHE ENABLED  to  true   Then all requests will be fetched and or cached as though the header  X Vault Cache Control  cache  was present  Setting the header to  nocache  on a request will opt out of caching entirely in this configuration  Setting the header to  recache  will skip the cache lookup and return and cache the response from Vault as described previously        Warning    The Vault Lambda Extension s cache is only in memory and will not be persisted when the Lambda execution environment shuts down  In order words  the cache TTL is capped to the duration of the Lambda execution environment      Limitations  Secrets written to disk or returned from the proxy server will not be automatically refreshed when they expire  This is particularly important if you configure the extension to write secrets to disk  because the extension will only write to disk once per execution environment  rather than once per function invocation  If you use  provisioned concurrency  https   docs aws amazon com lambda latest dg configuration concurrency html configuration concurrency provisioned  or if your Lambda is invoked often enough that execution contexts live beyond the lifetime of the secret  then secrets on disk are likely to become invalid   In line with  Lambda best practices  https   docs aws amazon com lambda latest dg best practices html   we recommend avoiding writing secrets to disk where possible  and exclusively consuming secrets via the proxy server  However  the proxy server will still not perform any additional processing with returned secrets such as automatic lease renewal  The proxy server s own Vault auth token is the only thing that gets automatically refreshed  It will synchronously refresh its own token before proxying requests if the token is expired  including a grace window   and it will attempt to renew its token if the token is nearly expired but renewable  The proxy will also immediately refresh its token if the incoming request header  X Vault Token Options  revoke  is present    Note title  Not SnapStart compatible      The Vault Lambda extension does not currently  work with    AWS SnapStart  https   docs aws amazon com lambda latest dg snapstart html      Note      Performance impact  AWS Lambda pricing is based on  number of invocations  time of execution and memory used  https   aws amazon com lambda pricing    The following table details some approximate performance related statistics to help assess the cost impact of this extension  Note that AWS Lambda allocates  CPU power in proportion to memory  https   docs aws amazon com lambda latest dg configuration memory html  so results will vary widely  These benchmarks were run with the minimum 128MB of memory allocated so aim to give an approximate baseline     Metric           Value                                                                                Description                                                                                Derivation                                                                                Layer size       8 5MB                                                                                The size of the unpacked extension binary                                                                                ls  la                                                                                Init latency     8 5ms  standard deviation 2 4ms    one network round trip to authenticate to Vault   Extension initialization time in a new execution environment  Authentication round trip time will be highly deployment dependent   Instrumented in code                                                                   Invoke latency    1ms                                                                                The base processing time for each function invocation  assuming no calls to the proxy server                                       Instrumented in code                                                                   Memory impact    12MB                                                                                The marginal impact on  Max Memory Used  when running the extension                                                                As reported by Lambda when running Hello World function with and without extension       Uploading to your own AWS account and region  If you would like to upload the extension as a Lambda layer in your own AWS account and region  you can do the following      shell session   curl   silent https   releases hashicorp com vault lambda extension 0 5 0 vault lambda extension 0 5 0 linux amd64 zip       output vault lambda extension zip      Set your target AWS region      shell session   export REGION  YOUR REGION HERE       Upload the extension as a Lambda layer      shell session   aws lambda publish layer version          layer name vault lambda extension          zip file   fileb   vault lambda extension zip           region    REGION           Tutorial  For step by step instructions  refer to the  Vault AWS Lambda Extension   vault tutorials app integration aws lambda  tutorial for details on how to create an AWS Lambda function and use the Vault Lambda Extension to authenticate with Vault