Deploying HashiCorp Vault in a validated pattern

Prerequisites

You have deployed/installed a validated pattern using the instructions provided for that pattern. This should include setting having logged into the cluster using oc login or setting you KUBECONFIG environment variable and running a ./pattern.sh make install.

Setting up HashiCorp Vault

Any validated pattern that uses HashiCorp Vault already has deployed Vault as part of the ./pattern.sh make install. To verify that Vault is installed you can first see that the vault project exists and then select the Workloads/Pods:

The setup for HashiCorp Vault happens automatically as part of the ./pattern.sh make install command. A cronjob will run every five minutes inside the imperative namespace and unseal, initialize and configure the vault. The vault’s unseal keys and root token will be stored inside a secret called vaultkeys in the imperative namespace.

It is recommended that you copy the contents of that secret offline, store it securely, and then delete it. It will not be recreated after the vault is unsealed. You can back it up to a file with the following command: oc get -n imperative secrets/vaultkeys -o yaml > <path-to-secret-storage>/vault-unseal-keys.yaml. Then you may delete it from the cluster by running oc delete -n imperative secret/vaultkeys. The unseal keys will be needed to unseal the vault again should its pod be restarted. You can restore the vaultkeys with oc apply -f <path-to-secret-storage>/vault-unseal-keys.yaml and then wait for the CronJob called unseal-vault to run (the default is every five minutes). Remember to delete the vaultkeys secret again once the vault is unsealed

An example output from running the oc extract -n imperative secret/vaultkeys --to=- --keys=vault_data_json 2>/dev/null command:

{
    "recovery_keys_b64": [],
    "recovery_keys_hex": [],
    "recovery_keys_shares": 0,
    "recovery_keys_threshold": 0,
    "root_token": "hvs.VNFq7yPuZljq2VDJTkgAMs2Z",
    "unseal_keys_b64": [
        "+JJjKgZyEB1rbKlXs1aTuC+PBivukIlnpoe7bH4qc7TL",
        "X2ib6LNZw+kOQH1WYR9t3RE2SgB5WbEf2FfD40OybNXf",
        "A4DIhv9atLIQsqqyDAYkmfEJPYhFVuKGSGYwV7WCtGcL",
        "ZWkQ7+qtgmClKdlNKWcdpvyxArm07P9eArHZB4/CMZWn",
        "HXakF073+Kk7oOpAFbGlKIWYApzUhC/F1LDfowF/M1LK"
    ],
    "unseal_keys_hex": [
        "f892632a0672101d6b6ca957b35693b82f8f062bee908967a687bb6c7e2a73b4cb",
        "5f689be8b359c3e90e407d56611f6ddd11364a007959b11fd857c3e343b26cd5df",
        "0380c886ff5ab4b210b2aab20c062499f1093d884556e28648663057b582b4670b",
        "656910efeaad8260a529d94d29671da6fcb102b9b4ecff5e02b1d9078fc23195a7",
        "1d76a4174ef7f8a93ba0ea4015b1a5288598029cd4842fc5d4b0dfa3017f3352ca"
    ],
    "unseal_shares": 5,
    "unseal_threshold": 3
}

The vault’s root token is needed to log into the vault’s UI and the unseal keys are needed whenever the vault pods are restarted. In the OpenShift console click on the nine box at the top and click on the vault line:

Vault Nine Box

Copy the root_token field which in the example above has the value hvs.VNFq7yPuZljq2VDJTkgAMs2Z and paste it in the sign-in page:

After signing in you will see the secrets that have been created.

Unseal

If you don’t see the sign in page but instead see an unseal page, something may have happened the cluster and you need to unseal it again. Make sure that the imperative/vaultkeys secret exists and wait for the CronJob called unseal-vault inside the imperative namespace to run. Alternatively you could unseal the vault manually by running vault operator commands inside the vault-0 pod. See these instructions for additional information.

What’s next?

Check with the validated pattern instructions to see if there are further steps you need to perform. Sometimes this might be deploying a pattern on an edge cluster and checking to see if the correct Vault handshaking and updating occurs.