In order to tighten the security around access to secrets stored
in a Vault KV secrets backend, generate a secret_id for each
accessing unit, using a response wrapping token which is passed
over the relation to the consuming application.
The consuming application will then use this token out-of-band of
Juju to retrieve the secret_id associated with the AppRole ID
directly from Vault.
Add a new action 'refresh-secrets' to force a renewal of secret_id's
and associated one-shot retrieval tokens across a deployment.
A token is only issued when a new approle is created or when
a refresh is initiated via the 'refresh-secrets' action.
Provide implementation for the provides endpoint of the vault-kv
typed interface.
This interface type will setup a KV secret backend and create an
approle and policy to allow remote services to access the backend
using the Vault API.
Backends may be shared between remote units, allowing any unit to
access any value in the backend, or may be isolated between units
based on path suffixing using the units hostname so that stored
secrets are not visible between units of a deployment.
The auto-unlock option intialises vault and stores the keys and
root token in the leadership database. This option should
only be used in testing as it is probably undesirable to
store the vault keys in the leader db from a security pov.
