Google Secrets Manager Kubernetes controller
Categories:
In Jenkins X Labs we have been working with Google Secrets Manager (which is currently in Beta so may still change). It is an extremely nice experience and if you also use Google Container Engine (GKE), Google’s managed Kubernetes service then we can make use of another cool feature, Workload Identity to automatically access secrets in their hosted service using a Kubernetes service account.
One of the initial challenges we had was we didn’t see an obvious way to automatically create Kubernetes secrets that include the data stored from Secrets Manager. So we created a little standalone controller that runs in a Kubernetes cluster and watches for Kubernetes secrets. When one is added or updated with a particular annotation the controller will access the secret using its ID in Secrets Manager and update the Kubernetes secret with the value.
Example
Full docs and code can be found here: https://github.com/jenkins-x-labs/gsm-controller/blob/master/README.md
TL;DR
Create an empty secret
kubectl create secret generic my-secret
Add the magic annotation that the controller uses to lookup the correct secret in Googles Secret Manager
kubectl annotate secret my-secret jenkins-x.io/gsm-secret-id=foo
Optionally if you want the Kubernetes secret to use a specific key for the data you can add another annotation
kubectl annotate secret my-secret jenkins-x.io/gsm-kubernetes-secret-key=credentials.json
Demo
Feadback
This is still early days and we’d love folks to try it and provide feedback (slack or the new labs issues) on whether it is useful to others and how we can improve it together.
On Jenkins X we make use of Hashicorp’s Vault which is great although it is another service users have to run, manage and upgrade. Wherever possible Jenkins X aims to use the Cloud well, so when users are installing Jenkins X onto a Cloud Provider we would like to leverage their other managed services, reducing the deployments we need to run in users clusters for Jenkins X.