From d78a90b3aef95a7a7a15bcff614bee523cdbed29 Mon Sep 17 00:00:00 2001 From: Liam Young Date: Wed, 4 Jul 2018 09:53:32 +0100 Subject: [PATCH] Increase vault init token use limit The documentation for vault suggests creating a token from the root token specifically for the vault authorisation action. To lock the token down the number of times the token can be used is set. The charm action uses the token multiple times so the action fails. Since the token is created with a relatively short ttl it seems reasonable to remove the usage limit entirely. Feedback from users has shown that when following the documentation the need to unseal each vault unit individually was missed so this instruction is now next to the unseal explanation as well as being reiterated in the HA section. When deploying an HA configuration etcd must support etcd3, this requirement was lacking in the instructions so it has been added. Change-Id: I07c233ccadd52ec7fe2fff6276e56cd88c48acf1 Closes-Bug: #1779875 --- deploy-guide/source/app-vault.rst | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/deploy-guide/source/app-vault.rst b/deploy-guide/source/app-vault.rst index d655f16..ddf5cb8 100644 --- a/deploy-guide/source/app-vault.rst +++ b/deploy-guide/source/app-vault.rst @@ -99,7 +99,9 @@ and an initial root token for accessing the Vault API. Do not lose the root token! Without it the vault deployment will be inaccessible. -you can then unseal the vault deployment for operation: +Each vault unit must be individually unsealed, so if there are multiple vault +units repeat the unseal process below for each unit changing the VAULT_ADDR +environment variable each time to point at the individual units. .. code:: bash @@ -122,7 +124,7 @@ initial root token for this purpose: .. code:: bash export VAULT_TOKEN=ebded15e-c908-5d3a-1df0-1e7e7218c162 - vault token create -use-limit=1 -ttl=10m + vault token create -ttl=10m you should get a response like: @@ -152,7 +154,10 @@ Enabling HA The vault charm supports deployment in HA configurations; this requires the use of etcd to provide HA storage to vault units, with access to -vault being provided a virtual IP or DNS-HA hostname: +vault being provided a virtual IP or DNS-HA hostname. + +The etcd application needs to support etcd3 so ensure it is using the latest +snap channel which supports it: .. code:: bash @@ -163,7 +168,7 @@ vault being provided a virtual IP or DNS-HA hostname: juju deploy hacluster vault-hacluster juju add-relation vault vault-hacluster - juju deploy --to lxd:0 etcd + juju deploy --config channel=3.1/stable --to lxd:0 etcd juju add-unit --to lxd:1 etcd juju add-unit --to lxd:2 etcd @@ -181,5 +186,5 @@ active vault unit over a secure cluster connection between units. When deploying vault in HA configurations, all vault units must be unsealed using the unseal keys generated during initialization - in order to unlock the master key. This is performed externally + in order to unlock the master key. This is performed externally to the charm using the Vault API.