Vault
What is Vault
Hashicorp Vault is an open source project for securely managing secrets. Secrets are resources that provide authentication to your computing environment such as tokens, keys, passwords, and certificates. Vault is the preferred way in Jenkins X to manage these secrets. For example, the GitHub personal access token generated for the pipeline bot is stored in Vault.
There are two ways you can use Vault in Jenkins X. If you are already a Vault instance, you can configure Jenkins X to use this instance to store its secrets. This way you have a central location for managing all secrets of your infrastucture. If you do not have a Vault instance, Jenkins X can, depending on where you run your cluster, install Vault as part of the installation process. In this case, the Banzai Cloud Bank-Vaults operator is provisioned in the Jenkins X development namespace.
Configuration
The configuration of Vault occurs during Jenkins X Boot. Refer to the Boot setup instructions for Vault to see how to configure Jenkins X to use an internal or external Vault instance.
Security
From a security point of view it is important that the communication with the Vault API is secured by TLS. If you use your own external Vault instance, TLS configuration is in your hands and hopefully already setup. If you let Jenkins X install and manage the Bank-Vaults operator, TLS is per default not enabled. Refer to Configuring DNS and TLS on GKE and Configuring DNS and TLS on EKS for more information on how to secure your Jenkins X installation using TLS for the cloud providers Google and AWS.
Accessing secrets
You can read and write secrets stored in Vault from the command line.
To do so, you need first to download an install the vault
CLI.
Once you have vault
installed you can configure your terminal session to connect to Vault by running:
eval `jx get vault-config`
Listing secrets
You can start exploring the Jenkins X secrets stored in Vault by runnning:
vault kv list secret
secret is the default mount point for the Jenkins X secrets. If you are using an external Vault instance this mount point is configurable via the secretEngineMountPoint option in jx-requirements.yml. You find more information in the Vault configuration paragraph of the Boot documentation.
The Vault configuration is also stored in the jx-install-config ConfigMap of your Jenkins X development namespace. You can retrieve it by running:
kubectl get cm jx-install-config -o=jsonpath="{.data['vaultSecretEngineMountPoint']}"
Reading secrets
You can then read a secret via:
vault kv get secret/<cluster-name>/pipelineUser
Updating secrets
You can update a secret via:
vault kv put secret/<cluster-name>/pipelineUser token=<token-value>
If you have a blob of JSON to encode as a secret, such as a service account key then base64 encode the data first:
cat my-service-account.json | base64 > my-service-account-base64.txt
vault kv put secret/<cluster-name>/my-secret token=my-service-account-base64.txt
Rotating secrets
To rotate a secret, follow the steps described in the Updating a secret section followed by rerunning Boot (jx boot
).
The reason you need to run Boot, either locally or kicking of the master pipline of the dev repository, is that as part of the Boot process the secrets within Vault get copied into appropriate Kubernetes Secrets which then are accessed by the various components of Jenkins X.
Without running Boot the changes to Vault will not take effect yet.
Feedback
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.