STATUS : I am not maintaining this anymore. Cloudwatt is maintaining it here https://github.com/cloudwatt/kubernetes-flexvolume-vault-plugin

Generally speaking I strongly suggest you move away from this approach now that Vault has a built-in kubernetes authentification backend. https://www.vaultproject.io/docs/auth/kubernetes.html

What is this ?

This project is an implementation of the flexvolume kubernetes plugin to inject a scoped vault token inside pods at startup so they can get their secrets, via consul-template for instance.

How do I build it ?

Just run make ( or go build -o whatever . where whatever is the name you want the binary to have ) By default the name of the binary is vaulttmpfs All dependencies are vendored under /vendor with glide and commited, so you can build with just the go toolchain..

You can also go get github.com/fcantournet/kubernetes-flexvolume-vault-plugin

How does it work ?

It creates a tmpfs volume and mounts it at a path specify by the kubelet. Inside the volume are 2 files with a configurable basename:

• basename that contains the raw wrapped vault token.
• basename.json that contains the full response from vault at token creation time (includes some vault metadata)

The token is scoped to a policy defined by a parameter provided to the plugin via stdin by the kubelet (cf. flexvolume documentation)

The binary generated by the project must be present on the node in at a specific path under the directory specified to the kubelet by the flag --volume-plugin-dir (cf. kubelet flexvolume documentation) By default : $VOLUME_PLUGIN_DIR/exec/cloudwatt~vaulttmpfs/vaulttmpfs

Then you can refer to this volume in a pod like so :

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: secret
      mountPath: /crazy
  dnsPolicy: Default
  volumes:
  - name: secret
    flexVolume:
      driver: "cloudwatt/vaulttmpfs"
      fsType: "tmpfs"
      options:
        vault/policies: "nginx"

It expects a vault token at a configurable path (set by VAULTTMPFS_GENERATOR_TOKEN_PATH) with a policy that allows the creation of token against the application_role (set by VAULTTMPFS_ROLE_NAME)

e.g : if the application_role is super_role then the policy should give write access to auth/token/create/super_role

An example of the policy is given in policies/token_generator_policy.hcl

Configuration

Since the kubelet runs the plugin with a fixed set of arguments we can't pass configuration via flags in the command line. We therefore use environment variables. The process inherits all the environment from the kubelet.

The plugin supports some the standard vault environment variables as defined here (it calls config.ReadEnvironment()) This means that all the defaults for these are set by Vault and the default value specified in the table below are subject to being FALSE (althought you should probably never use default values) Vault loads system's CAs by default, but you can specifiy a custom CA certificate with VAULT_CACERT or VAULT_CAPATH.

Additionally we have variables to configure settings external to vault. These are prefixed with VAULTTMPFS_ so as to not conflict with anything else.

(non-exhaustive) Table of supported configuration variables :

Environment Variable	default	Description
VAULTTMPFS_GENERATOR_TOKEN_PATH	/etc/kubernetes/vaulttoken	The path to load the token used by this service from.
VAULTTMPFS_TOKEN_FILENAME	vault-token	The name of the file in the created volume that will contain the wrapped token
VAULTTMPFS_ROLE_NAME	applications	The role in auth/token against which the tokens will be created
VAULT_ADDR	https://127.0.0.1:8200	The vault server URL
VAULT_TLS_SERVER_NAME	""	If set, use the given name as the SNI host when connecting via TLS.
VAULT_WRAP_TTL	5m	TTL of the wrapped Token inserted in the volume.
VAULT_MAX_RETRY	2	The maximum number of retries when a 5xx error code is encountered. Default is 2, for three total tries; set to 0 or less to disable retrying

Bootstrap

There is an helper command to bootstrap a node with a token for the token generator policy. It supports 2 authentification methods : interactive LDAP auth (needs to be configured and activated in vault), or that you have (root) VAULT_TOKEN set in the environment. just run : vaulttmpfs bootstrap

You need to have VAULT_ADDR set as an environment variable