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

[zxhdaze]

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.

---

Imported from Launchpad using lp2gh.

• date created: 2022-02-11T18:16:39Z

• owner: thogarre

• assignee: None

• the launchpad url

[zxhdaze]

(by aurelien-lourot) 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.

[zxhdaze]

(by chris.sanders) Subscribing field high based on recent deployments which this the CSR processes is making miss deliveries.

[zxhdaze]

(by james-page) 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.

[zxhdaze]

(by billy-olsen) FieldSLA is not applicable for features. This does look like an important feature request and have noted it for planning information.

[zxhdaze]

(by aurelien-lourot) 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.

[zxhdaze]

(by chris.sanders) Subscribing field high based on recent deployments which this the CSR processes is making miss deliveries.

[zxhdaze]

(by james-page) 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.

[zxhdaze]

(by billy-olsen) FieldSLA is not applicable for features. This does look like an important feature request and have noted it for planning information.