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

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.

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

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

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 :

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