Hi, we are having Vault instance that was running in kubernetes cluster. Currently our cluster is broken, so we are not able to access Vault. I can see that Vault secrets and data are stored in s3 bucket, whic I can access. I also have a ROOT token. Is it possible to move the data from old to new Vault instance (s3 data is encrypted)
If the broken Vault was using the default Shamir seal method: Do you have a quorum of unseal keys?
If the broken Vault was using auto-unseal of any type: Is the auto-unseal method still available?
If the answer is no, then you cannot recover any data from this Vault, as the relevant decryption key is gone.
EDIT: If you are uncertain about the seal method, please post the Vault server’s configuration file.
Hi, it was using auto-unseal managed in kubernetes.
This is its config
We also have 3 access keys that we were using to unseal the vault from the UI
The information you’ve given still leaves me uncertain - you’ve said:
except Kubernetes is not a type of auto-unseal.
The YAML you have screenshotted does not look like actual Vault configuration - rather it is input to some custom automation of your own, so it does not clear things up.
Whether those are still useable depends on the auto-unseal questions.
Hi, this is the Helm chart config for Vault unseal chart. So as I can see it seems that AWS KMS is used for vault unsealing.
Did you mean to paste some config to go along with this sentence?
Assuming you are correct about the AWSKMS seal (the fact you mentioned having to input keys into the UI makes me hesitate about this), then you can just deploy a new Vault instance anywhere you like to access your data, provided it can reach your S3 and AWSKMS.
apologies, I wanted to attach this as a helm chart definition. Can you suggest some manual how to deploy a new Vault instance (sorry, Vault noob here) and connect to the S3 and AWS KMS data?
That is not a helm chart definition. It’s just more input to some custom automation of your own, and still doesn’t clear anything up.
Please feel free to refer to any of the many different pieces of documentation HashiCorp have out there for different deployment scenarios.
I can’t be any more helpful than that since it’s highly dependent on your own architectural choices.