Delinea DevOps Secrets Vault Kubernetes Secret Injector and Syncer

The DSV Kubernetes Injector and Syncer are components for Kubernetes. The Mutating Webhook injects Secret data from the Delinea DevOps Secrets Vault (DSV) into Kubernetes Secrets, and a CronJob periodically synchronizes them. The webhook can run as a pod or a stand-alone service, and the cronjob can run inside or outside the cluster.

dsv-injector: Intercepts CREATE Secret admissions and then mutates the Secret with data from DSV.
dsv-syncer: The syncer scans the cluster (or a single namespace) for Secrets that were mutated, compares the secret version, and updates if the secret has changed versions.

The common configuration consists of one or more Client Credential Tenant mappings. The credentials are then specified in an Annotation on the Kubernetes Secret to be mutated.

The webhook and syncer use the Golang SDK to communicate with the DSV API. They were tested with Docker Desktop and Minikube. They also work on OpenShift, Microk8s and others.

Supporting Docs

The docs directory has supporting documentation that goes into more detail on the developer workflows, test setup, configuration, helm install commands, and more.

Injector & Syncer Differences

Injector: This is a mutating webhook using AdmissionController. This means it operates on the CREATE of a Secret, and ensures it modified before finishing the creation of the resource in Kubernetes. This only runs on the creation action triggered by the server.
Syncer: In contrast, the syncer is a normal cronjob operating on a schedule, checking for any variance in the data between the Secret data between the resource in Kubernetes and the expected value from DSV.

Which Should I Use?

Both: If you want a secret to be injected on creation and also synced on your cron schedule then use the Injector and Syncer.
Injector: If you want the secret to be static despite the change upstream in DSV, and will recreate the secret on any need to upgrade, then the injector. This will reduce the API calls to DSV as well.
Syncer: If you want the secret value to be updated within the targeted schedule automatically. If this is run by itself without the injector, there can be a lag of up to a minute before the syncer will update the secret. Your application should be able to handle retrying the load of the credential to avoid using the cached credential value that might have been loaded on app start-up in this case.

Quick Start

Since there's a mix of users for this repo, here's where to go for getting up and running as quickly as possible.

Who	Where do I start?
👉 I just want to install the helm charts against my own cluster.	Clone, and use `helm install` against the charts directory.
👉 I'm a contributor/developer and want to test/build locally	Use the setup-developer guide.
👉 I'm a contributor and need to create a release.	Use the release guide.

Build

To build run: mage init build. For more detailed directions on local development (such as Mage), see setup-developer

Test

See details in local-testing

Reference Mage Tasks

Manually updated, for most recent Mage tasks, run mage -l.

Target	Description
build	🔨 Build builds the project for the current platform.
buildAll	🔨 BuildAll builds all the binaries defined in the project, for all platforms.
clean	up after yourself.
go:doctor	🏥 Doctor will provide config details.
go:fix	🔎 Run golangci-lint and apply any auto-fix.
go:fmt	✨ Fmt runs gofumpt.
go:init	⚙️ Init runs all required steps to use this package.
go:lint	🔎 Run golangci-lint without fixing.
go:lintConfig	🏥 LintConfig will return output of golangci-lint config.
go:test	🧪 Run go test.
go:testSum	🧪 Run gotestsum (Params: Path just like you pass to go test, ie ./..., pkg/, etc ).
go:tidy	🧹 Tidy tidies.
go:wrap	✨ Wrap runs golines powered by gofumpt.
helm:docs	generates helm documentation using `helm-doc` tool.
helm:init	⚙️ Init sets up the required files to allow for local editing/overriding from CacheDirectory.
helm:install	🚀 Install uses Helm to install the chart.
helm:lint	🔍 Lint uses Helm to lint the chart for issues.
helm:render	💾 Render uses Helm to output rendered yaml for testing helm integration.
helm:uninstall	🚀 Uninstall uses Helm to uninstall the chart.
init	runs multiple tasks to initialize all the requirements for running a project for a new contributor.
installTrunk	installs trunk.io tooling if it isn't already found.
job:init	runs the setup tasks to initialize the local resources and files, without trying to apply yet.
job:redeploy	removes kubernetes resources and helm charts and then redeploys with log streaming by default.
k8s:apply	applies a kubernetes manifest.
k8s:delete	Apply applies a kubernetes manifest.
k8s:init	copies the k8 yaml manifest files from the examples directory to the cache directory for editing and linking in integration testing.
k8s:logs	streams logs until canceled for the dsv syncing jobs, based on the label `dsv.delinea.com: syncer`.
kind:destroy	🗑️ Destroy tears down the Kind cluster.
kind:init	➕ Create creates a new Kind cluster and populates a kubeconfig in cachedirectory.
minikube:destroy	🗑️ Destroy tears down the Kind cluster.
minikube:init	➕ Create creates a new Minikube cluster and populates a kubeconfig in cachedirectory.
release	🔨 Release generates a release for the current platform.
trunkInit	ensures the required runtimes are installed.