Using Vault Agent Templating in the mutating webhook
With Bank-Vaults you can use Vault Agent to handle secrets that expire, and supply them to applications that read their configurations from a file.
When to use vault-agent
- You have an application or tool that requires to read its configuration from a file.
- You wish to have secrets that have a TTL and expire.
- You have no issues with running your application with a sidecar.
Note: If you need to revoke tokens, or use additional secret backends, see Using consul-template in the mutating webhook.
- Your pod starts up, the webhook will inject one container into the pods lifecycle.
- The sidecar container is running Vault, using the vault agent that accesses Vault using the configuration specified inside a configmap and writes a configuration file based on a pre configured template (written inside the same configmap) onto a temporary file system which your application can use.
This document assumes the following.
You have a working Kubernetes cluster which has:
- a working Vault installation
- a working installation of the mutating webhook.
You have a working knowledge of Kubernetes.
You can apply Deployments or PodSpec’s to the cluster.
You can change the configuration of the mutating webhook.
Use Vault TTLs
If you wish to use Vault TTLs, you need a way to HUP your application on configuration file change. You can configure the Vault Agent to execute a command when it writes a new configuration file using the
command attribute. The following is a basic example which uses the Kubernetes authentication method.
To configure the webhook, you can either:
- set some sane defaults in the environment of the mutating webhook, or
- configure it via annotations in your PodSpec.
Enable vault agent in the webhook
For the webhook to detect that it will need to mutate or change a PodSpec, add the
vault.security.banzaicloud.io/vault-agent-configmap annotation to the Deployment or PodSpec you want to mutate, otherwise it will be ignored for configuration with Vault Agent.
Defaults via environment variables
|the vault image to use for the sidecar container
|The pull policy for the vault agent container
|Kubernetes service Vault endpoint URL
|supply a secret with the vault TLS CA so TLS can be verified
|Kubernetes version <1.12 default off, 1.12 or higher default on
|Same as VAULT_ADDR above
|Same as VAULT_TLS_SECRET above
|A configmap name which holds the vault agent configuration
|do not run vault-agent in daemon mode, useful for kubernetes jobs
|Same as VAULT_AGENT_SHARE_PROCESS_NAMESPACE above
|Specify the vault-agent container CPU resource limit
|Specify the vault-agent container memory resource limit
|Mount path of Vault Agent rendered files