Applications expecting Kubernetes Secrets or ConfigMaps may need values maintained centrally in Vault. vaultingkube polled Vault paths and synchronized matching values into those Kubernetes objects, using path conventions to decide their names and namespaces. The project is archived. An existing deployment also manages object deletion, so transferring it to another controller requires an explicit mapping and ownership handover. Verify how applications reload changed values and what happens when a source path or the Vault service becomes unavailable.
Current guidance
This entry identifies sunshinekitty/vaultingkube, a polling synchronizer that maps Vault paths to Kubernetes ConfigMaps and Secrets. The repository is archived. Its README documents old client versions and says it manages objects carrying the vaultingkube.io/managed annotation, deleting managed objects that disappear from Vault by default.
HashiCorp’s current Vault Secrets Operator is a supported alternative pattern for synchronizing Vault secrets, but it uses explicit custom resources and different authentication and lifecycle rules. It is not a drop-in replacement for vaultingkube’s path naming scheme or ConfigMap behavior. Decide whether workloads need Kubernetes Secrets, direct mounts or another supported delivery model before translating configuration.
Export the source-to-destination mapping and identify every managed object before changing controllers. Rehearse ownership transfer without allowing two reconcilers to overwrite or delete the same Secret, and preserve the credentials needed for recovery. Test rotation, Vault unavailability and application reload behavior, including the difference between environment variables and mounted files. Keep deletion disabled or tightly controlled during a documented handover rather than discovering the old default after source paths have been reorganized.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub marks sunshinekitty/vaultingkube as archived. This confirms the repository's read-only archive state; any successor or supported distribution needs separate evidence. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
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 vaultingkube.io/managed: “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 vaultingkube.io/managed: “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
Sources & further reading
Spotted something that needs another look?
Help improve this page →