Vault-CRD
Today I’ve finished my work on release-1.0.0 of Vault-CRD a Kubernetes custom resource definition for sharing secrets stored in HashiCorp Vault with Kubernetes.
What is HashiCorp Vault
HashiCorp Vault is an application for securly storing secrets and accessing them from different types of applications or deployment scripts. The interresting part is handling of dynamic secrets, for example to access databases, encrypt data and leasing and renewal of secrets.
But why Vault-CRD?
In times of Cloud native applications and especially in configuration management it’s important to access secrets easily but secure. That’s where Vault comes into its own. There are dozens of frameworks like Spring Cloud Vault that makes it easy to access secrets from Vault inside of applications. But what about applications that are older then the word Cloud native? Or what about renewal of certificates for ingress or applications that are not Let’s Encrypt certificates?
That’s why I developed Vault-CRD.
What does Vault-CRD do?
Vault-CRD is a custom resource definition for sharing secrets that are stored in HashiCorp Vault with Kubernetes secrets. Vault-CRD runs for example inside your Kubernetes Cluster and watches for new resources of type Vault.
If there are new resources it shares the values from HashiCorp Vault with Kubernetes secrets and updates them if they change. So it’s possible to hold changes in HashiCorp Vault up to date with Kubernetes secrets. If there is a change in HashiCorp Vault the Vault-CRD detects it and updates the Kubernetes secrets.
Simple example
We are creating a new resource of type Vault that has the following content
apiVersion: "koudingspawn.de/v1"
kind: Vault
metadata:
name: test-secret
spec:
type: "KEYVALUE"
path: "secret/test-secret"
and applying it to Kubernetes:
kubectl apply -f test-secret.yaml
Now Vault-CRD connects to Vault and tires to find the secret secret/testsecret and shares the values with Kubernetes. Here you can see the output after Vault-CRD found the new resource:
$ kubectl get vault test-secret
NAME AGE
test-secret 7d
$ kubectl get secret test-secret
NAME TYPE DATA AGE
test-secret Opaque 2
Now you can access the secret and inside the key/value pairs of the Vault secret are mapped.
But there is more then only the KEYVALUE type:
- PKI: The PKI-Type is made to connect to the PKI - Secrets Engine of HashiCorp Vault. It generates certificates X.509 Certificates and refreshes them if they are near the expiration date.
- PKIJKS: The PKIJKS-Type is the same as the PKI-Type. The only difference is that it converts the issued certificate into a Java Key Store.
- CERT: The Certificate-Type is similar to a KEYVALUE-Type but the data has to be saved in a specific order. The reason for this is, that when you issue a new certificate from a PKI Secret Engine in Vault they are wrapped in a second data object.
- CERTJKS: The CERTJKS-Type is the same as the CERT-Type. The only difference is that it converts the saved Certificate into a Java Key Store.
- DOCKERCFG: The DOCKERCFG-Type is for syncing the Pull-Credentials for secured Docker repositories.
And the interresting part here is, if a Secret changes or the TTL of the issued certificate expires Vault-CRD refreshes the value in Kubernetes with the changes or issues a new certificate.
More details
For more details please see the Documentation of the Vault-CRD Project here: https://vault.koudingspawn.de
And on Github you can find the latest source code: https://github.com/DaspawnW/vault-crd
