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.

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.