vaultingkube takes config maps and secrets stored inside Hashicorp Vault and syncs them to your Kubernetes cluster.

How Did It Work?

After Vaultingkube is running in your cluster it will look at the Vault server configured via the Vault client config options. Based on the VK_VAULT_ROOT_MOUNT_PATH Vaultingkube will read all kV secrets it has access to and references any with a matching mount path. EG if VK_VAULT_ROOT_MOUNT_PATH is set to vaultingkube/my-cluster it will look at all mounts at vaultingkube/my-cluster/*.

The type of secret and namespace are configured in the mount path as well. It looks like [VK_VAULT_ROOT_MOUNT_PATH]/[NAMESPACE]/[SECRET_TYPE]/[NAME]. If I wanted to create a config map in the default namespace named tom I would create a kV secret at [VK_VAULT_ROOT_MOUNT_PATH]/default/config maps/tom.

Vaultingkube will only overwrite, manage, or delete ConfigMaps and Secrets that have the annotation “true” set. You will need to manually set this on existing Secrets and Configmaps for Vaultingkube to take over.

Vaultingkube does not have any logic to determine if Vault has changed, and so it uses the VK_SYNC_PERIOD environment variable to determine how frequently (in seconds) it sends update requests to Kubernetes to stay in sync with Vault.

By default Vaultingkube will delete ConfigMaps and Secrets that exist in Kubernetes and not Vault that have the annotation of “true”. To turn this to offset the environment variable VK_DELETE_OLD to “false”.


You should be able to infer the supported versions of Kubernetes and Vault that will work with this program from these.

  • client-go: 5.0.1
  • vault: 0.9.0

Tell us about a new Kubernetes application


Never miss a thing! Sign up for our newsletter to stay updated.


Discover and learn about everything Kubernetes