Skip to content

A Delinea DevOps Secrets Vault Kubernetes Secrets Injector and Syncer

License

Notifications You must be signed in to change notification settings

DelineaXPM/dsv-k8s

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Delinea DevOps Secrets Vault Kubernetes Secret Injector and Syncer

All Contributors

Docker Pulls

Docker Image Version (latest semver)

Tests

Release

Red Hat Quay

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.

Contents

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.

Contributors

Thanks goes to these wonderful people (emoji key):


Adam C. Migus

πŸ’» πŸ“– ⚠️

sheldonhull

πŸ’» πŸ“– ⚠️

Hans Boder

πŸ›

tylerezimmerman

🚧

Tim Krehl

🚧

Ricky White

🚧

John Poulin

🚧

This project follows the all-contributors specification. Contributions of any kind welcome!