5df2842...
by
OpenDev Sysadmins <email address hidden>
OpenDev Migration Patch
This commit was bulk generated and pushed by the OpenDev sysadmins
as a part of the Git hosting and code review systems migration
detailed in these mailing list posts:
Attempts have been made to correct repository namespaces and
hostnames based on simple pattern matching, but it's possible some
were updated incorrectly or missed entirely. Please reach out to us
via the contact information listed at https://opendev.org/ with any
questions you may have.
Vault version in snap store may not start with 'v'
The nagios check that checks the snap store version matches the
deployed assumes that the version info in the snap store starts
a 'v'. If it doesn't it return None. This fixes that.
Change-Id: I89f56866c78b286e7d07b43432d56aa41a0c2eb9
(cherry picked from commit e0030882773aaa18078d8dc1d1eab122ebafcd2f)
To use the tls-certificates interface clients relate to the vault
charm. If the charms CA is not ready yet the charm will not update
the relation data. To prepare the CA an operator needs to run the
get_csr action to retrieve the csr for the intermediate ca the charm
has prepared. The operator should sign the csr with the root CA and
then upload the root CA cert and signed csr to the vault charm via
the upload-signed-csr action. Running this action will trigger the
vault charm to process any outstanding certificate requests and to
update the relation data accordingly.
The update includes:
* New action get_csr to retrieve a csr for the intermediate ca for
the charm pki
* New action upload-signed-csr to upload a signed intermediate csr
* Charm now provides tls-certificates interface
* Update vault access acl to allow charm full access to charm-pki-*.
Currently the only pki mount point the charm uses is
charm-pki-local
* Various generic helpers to lib.charm.vault
* New module lib.charm.vault_pki which handles interactions between
the charm and the vault pki api
* Add handler to reactive.vault_handlers for reacting to certificate
requests
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.
