[feature] add vault action to backup and restore keys and certificates

Bug #1893471 reported by Jeff Hillman
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
charm-juju-backup-all
New
Medium
Unassigned
juju-backup-all
New
Medium
Unassigned
vault-charm
Triaged
Wishlist
Unassigned

Bug Description

having a juju action to backup and then restore the vault keys and certificates between deploys can be very useful.

1) from a DR scenario
2) vault migration scenario
3) when testing multiple deploys for customers and they have a lengthy signing process that is cumbersome for all parties.

Specifically around #3, field will deploy the cloud many times to ensure consistency and to resolve issues found along the way. On each new deploy, today, a new CSR must be created and it signed. This can slow down deployments, and be annoying to the customer to have to submit ticket after ticket to sign a CSR. Using an auto-generated root-ca doesn't emulate the environment or process properly.

If the keys for vault and certs could be backed up and then restored, this can expedite this process.

Revision history for this message
Aurelien Lourot (aurelien-lourot) wrote :

Hi Jeff, thanks for the feature request! I understand that you're not talking about the keys used for initializing/unsealing the vault but you're basically talking about exporting/importing all secrets included in the vault (no matter whether they are keys, certs, passphrases, whatever). I'm just stating this here explicitly for future travelers.

Changed in vault-charm:
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
Chris Sanders (chris.sanders) wrote :

Subscribing field high based on recent deployments which this the CSR processes is making miss deliveries.

Revision history for this message
James Page (james-page) wrote :

In terms of feasibility it may be possible to use the "operator migrate" commands to facilitate a secure backup and restore between a MySQL backend and a filesystem.

https://www.vaultproject.io/docs/commands/operator/migrate

This is a direct backend migration i.e. no decryption is involved so the unseal keys will remain the same throughout the process.

This would also require a different path to initialisation of vault during deployment where a migrate from filesystem -> mysql is performed rather than the init process. We'd also need to deal with how the charm then gains access to vault so backup of the approle information the vault charm uses and direct injection of that during redeployment would need to be done.

Revision history for this message
Billy Olsen (billy-olsen) wrote :

FieldSLA is not applicable for features. This does look like an important feature request and have noted it for planning information.

tags: added: canonical-bootstack
Eric Chen (eric-chen)
Changed in charm-juju-backup-all:
importance: Undecided → Medium
Changed in juju-backup-all:
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.