Vault Agent Injector

The Vault Agent Injector alters pod specifications to include Vault Agent containers that render Vault secrets to a shared memory volume using Vault Agent Templates. By rendering secrets to a shared volume, containers within the pod can consume Vault secrets without being Vault aware.

The Vault Agent Injector is a fully supported component of HashiCorp Vault.

The injector is a Kubernetes Mutation Webhook Controller. The controller intercepts pod events and applies mutations to the pod if annotations exist within the request. This functionality is provided by the vault-k8s project and can be automatically installed and configured using the Vault Helm chart.

Supported kubernetes versions

The following Kubernetes minor releases are currently supported. The latest version is tested against each Kubernetes version. It may work with other versions of Kubernetes, but those are not supported.

• 1.32
• 1.31
• 1.30
• 1.29
• 1.28

Overview

The Vault Agent Injector works by intercepting pod CREATE and UPDATE events in Kubernetes. The controller parses the event and looks for the metadata annotation vault.hashicorp.com/agent-inject: true. If found, the controller will alter the pod specification based on other annotations present.

Mutations

At a minimum, every container in the pod will be configured to mount a shared memory volume. This volume is mounted to /vault/secrets and will be used by the Vault Agent containers for sharing secrets with the other containers in the pod.

Next, two types of Vault Agent containers can be injected: init and sidecar. The init container will prepopulate the shared memory volume with the requested secrets prior to the other containers starting. The sidecar container will continue to authenticate and render secrets to the same location as the pod runs. Using annotations, the initialization and sidecar containers may be disabled.

Last, two additional types of volumes can be optionally mounted to the Vault Agent containers. The first is secret volume containing TLS requirements such as client and CA (certificate authority) certificates and keys. This volume is useful when communicating and verifying the Vault server's authenticity using TLS. The second is a configuration map containing Vault Agent configuration files. This volume is useful to customize Vault Agent beyond what the provided annotations offer.

Authenticating with Vault

The primary method of authentication with Vault when using the Vault Agent Injector is the service account attached to the pod. Other authentication methods can be configured using annotations.

For Kubernetes authentication, the service account must be bound to a Vault role and a policy granting access to the secrets desired.

A service account must be present to use the Vault Agent Injector with the Kubernetes authentication method. It is not recommended to bind Vault roles to the default service account provided to pods if no service account is defined.

Requesting secrets

There are two methods of configuring the Vault Agent containers to render secrets:

• the vault.hashicorp.com/agent-inject-secret annotation, or
• a configuration map containing Vault Agent configuration files.

Only one of these methods may be used at any time.

Secrets via annotations

To configure secret injection using annotations, the user must supply:

• one or more secret annotations, and
• the Vault role used to access those secrets.

The annotation must have the format:

vault.hashicorp.com/agent-inject-secret-<unique-name>: /path/to/secret

The unique name will be the filename of the rendered secret and must be unique if multiple secrets are defined by the user. For example, consider the following secret annotations:

vault.hashicorp.com/agent-inject-secret-foo: database/roles/app
vault.hashicorp.com/agent-inject-secret-bar: consul/creds/app
vault.hashicorp.com/role: 'app'

The first annotation will be rendered to /vault/secrets/foo and the second annotation will be rendered to /vault/secrets/bar.

It's possible to set the file format of the rendered secret using the annotation. For example the following secret will be rendered to /vault/secrets/foo.txt:

vault.hashicorp.com/agent-inject-secret-foo.txt: database/roles/app
vault.hashicorp.com/role: 'app'

The secret unique name must consist of alphanumeric characters, ., _ or -.

Secret templates

How the secret is rendered to the file is also configurable. To configure the template used, the user must supply a template annotation using the same unique name of the secret. The annotation must have the following format:

vault.hashicorp.com/agent-inject-template-<unique-name>: |
  <
    TEMPLATE
    HERE
  >

For example, consider the following:

vault.hashicorp.com/agent-inject-secret-foo: 'database/creds/db-app'
vault.hashicorp.com/agent-inject-template-foo: |
  {{- with secret "database/creds/db-app" -}}
  postgres://{{ .Data.username }}:{{ .Data.password }}@postgres:5432/mydb?sslmode=disable
  {{- end }}
vault.hashicorp.com/role: 'app'

The rendered secret would look like this within the container:

$ cat /vault/secrets/foo
postgres://v-kubernet-pg-app-q0Z7WPfVN:A1a-BUEuQR52oAqPrP1J@postgres:5432/mydb?sslmode=disable

If no template is provided the following generic template is used:

{{ with secret "/path/to/secret" }}
    {{ range $k, $v := .Data }}
        {{ $k }}: {{ $v }}
    {{ end }}
{{ end }}

For example, the following annotation will use the default template to render PostgreSQL secrets found at the configured path:

vault.hashicorp.com/agent-inject-secret-foo: 'database/roles/pg-app'
vault.hashicorp.com/role: 'app'

The rendered secret would look like this within the container:

$ cat /vault/secrets/foo
password: A1a-BUEuQR52oAqPrP1J
username: v-kubernet-pg-app-q0Z7WPfVNqqTJuoDqCTY-1576529094

Renewals and updating secrets

For more information on when Vault Agent fetches and renews secrets, see the Agent documentation.

Vault agent configuration map

For advanced use cases, it may be required to define Vault Agent configuration files to mount instead of using secret and template annotations. The Vault Agent Injector supports mounting ConfigMaps by specifying the name using the vault.hashicorp.com/agent-configmap annotation. The configuration files will be mounted to /vault/configs.

The configuration map must contain either one or both of the following files:

• config-init.hcl used by the init container. This must have exit_after_auth set to true.
• config.hcl used by the sidecar container. This must have exit_after_auth set to false.

An example of mounting a Vault Agent configmap can be found here.

Injector telemetry

Vault Agent injector collects the following Prometheus metrics in addition to the default set of golang metrics:

• vault_agent_injector_request_queue_length - The number of pending webhook requests for the injector.

• vault_agent_injector_request_processing_duration_ms - A histogram of webhook request processing times in milliseconds.

• vault_agent_injector_injections_by_namespace_total - The total count of Agent container injections, grouped by Kubernetes namespace and injection_type. Vault Agent injector counts the following injection types:

  • init_only
  • sidecar_only
  • init_and_sidecar

• vault_agent_injector_failed_injections_by_namespace_total - The total count of failed Agent sidecar injections, grouped by Kubernetes namespace.

Tutorial

Refer to the Injecting Secrets into Kubernetes Pods via Vault Helm Sidecar guide for a step-by-step tutorial.