Using Vault for your Secret storage
Have you answered the Jenkins X survey yet?
If no, then
Jenkins X 3.x uses Kubernetes External Secrets to manage populating secrets from your underlying secret store such as:
- Alibaba Cloud KMS Secret Manager
- Amazon Secret Manager
- Azure Key Vault
- Hashicorp Vault
- GCP Secret Manager
This lets you check in all of your other kubernetes resources and custom resource definitions into git for simple and powerful GitOps.
You can then rotate secrets easily independent of git.
This is the exact same graph as here, with AWS Secrets Manager replaced by vault.
The following demo walks through how to manage External Secrets via GitOps:
To view which secrets have been populated use:
jx secret verify
This will list all of the
ExternalSecret resources and visualise which ones are populated correctly.
If you are using Vault as your back end for Kubernetes External Secrets then before you try any of the following commands to populate secrets you need to make sure your termminal can access Vault.
To do this you can run the jx secret vault portforward command in a terminal:
jx secret vault portforward
You should then be able to run the following
jx secret edit or
jx secret import commands.
To edit the Secrets use the jx secret edit command:
jx secret edit
This will prompt you to enter all the missing Secrets by default.
If you just want to enter a specific secret you can use
-f to filter for a specific secret name.
jx secret edit -f nexus
If you want to pick which secrets you wish to edit you can use interactive mode via:
jx secret edit -i
You will then be prompted for the Secret name to edit. When you pick a Secret name you are then prompted to pick the names of the properties in the secret you wish to edit.
Create a new Secret
If you wish to add a new custom Secret to your cluster so that you can reference it inside a Pipeline then follow these steps:
- Add an
Secretwith empty values) resource via the add a kubernetes resources guide.
- Submit your change as a Pull Request then merge the change.
- This should now trigger a boot Job to apply the changes in your repository
- You should now be able to see the
ExternalSecretin the namespace you wanted via:
kubectl get es --namespace jx
- You can view which External Secrets are populated via the External Secrets service via:
jx secret verify
Secretgets created by the the External Secrets service when the underlying secret store (e.g. vault / cloud provider secret manager) is populated or updated. You can populate the secrets in a number of ways…
- using the underlying secret store directly. e.g. using the vault CLI directly or vault web UI or use your cloud providers secret manager’s CLI or web UI
jx secret edit -f mysecret-name
- using a generator or template. You can define a
versionStream/charts/chartRepoName/chartName/secret-schema.yamlfile which describes how to generate the secret (e.g. using a random password generator or a template) such as this example to generate a dynamic password for MySQL
Replicating Secrets among namespaces
Its quite common to need to replicate the same Secrets across namespaces. For example Image Pull Secrets to pull images from container registries which may need to be used in dev, staging and production.
The Jenkins X boot job does this automatically for any secret labelled with
secret.jenkins-x.io/replica-source=true using the jx secret replicate command:
jx secret replicate --selector secret.jenkins-x.io/replica-source=true
This will replicate the secret to all permanent enivronments in the same cluster (e.g. a local Staging or Production environment).
Migrating Secrets from Vault
If you have secrets already in a Vault then use the vault CLI tool to export the secrets to disk, reformat it in the above YAML layout and then import the secrets as above.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.