I don't have enough rep to comment but I'm going to expand on what RuBiCK said.
In the first case, if you have a password for JIRA that I'm going to use to log in to the website with and fiddle with some tasks, then this goes in LastPass. You can store it there and use the extension or the vault to help me remember a complex password. You can also use ...
Vault will distribute multiple unseal keys but there's nothing to stop you from keeping all of the keys in one place for a personal project.
The one time I did it I set the keys to 3 and kept them in different physical locations along with online locations.
I assume your vault would be being accessed over a network, so you would ask a colleague to use their own command line on their own workstation to enter their key. Mine requires 3 keys to unseal so I just have 3 users independently enter the vault unseal command with their key.
If your secret backend is a separate service, which it should be, then with regular backups you should be able to stop vault, replace the backend with a backup and be good to go.
I've done this for a file backend but don't know what would happen for other backends so ymmv.
Assuming person B has a role which also allows them access to the path secret/hello, then they would simply run vault read secret/hello from their own machine.
If you're following the demo, I think the vault server will be on your local machine? So if someone else is to connect to it they would need to set VAULT_ADDR to point to the IP where the server is ...
Lastpass is for your personal (or team) passwords. I would not use Lastpass for storing credentials of service accounts.
Use HashiCorp's Vault or any other solution like Amazon KMS for infrastructure secrets.
The vault docs mention a -field parameter for the read subcommand. So you should be able to put this into a shell script:
SECRET=$(vault read secret/mysecret -field foo)
Other vault docs use the vault kv get in the same way so you might try:
SECRET=$(vault kv get secret/mysecret -field foo)
First chef runs as often as you configure it to do.
Second Chef is a configuration management system and not a crontab or an orchestration system.
Use chef to configure cron (that can not be not an option, try to find out why this is not considered) for your backup using consul-template to retrieve the secret from vault. Don't use Chef to run the backups ...
To my knowledge there are no services today that offer Vault SaaS. However, if you're looking for a better UI/UX, there are great options out there for a Vault UI (A full Hashicorp supported list can be found here). I've personally tried out both Cryptr and Goldfish and have found both to be robust and complete.
Well, the first step is to use a backend which supports HA. Consul, for example, supports HA. If you are not an enterprise customer, you may have to run a shell script via cron to upload consul snapshots to s3 or where ever you want to store them. Later, you can restore all your secrets. And obviously, the snapshots are encrypted.
I looked at Jenkins plugins for vault, but they only work for fetching secrets from Vault.
It depends how the current configuration looks like that is used to deploy apps.
If one uses Jenkins pipelines, then one could replace the keyId with the one that is defined in Hashicorp vault.
// define ...