6

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 ...


5

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.


4

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.


3

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 -field foo secret/mysecret) Other vault docs use the vault kv get in the same way so you might try: SECRET=$(vault kv get -field foo secret/mysecret)


3

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.


3

I think the answer should be yes to ecdsa but no to ed25519, but that it is currently no to both. You can externally generate an ecdsa keypair and load it into ssh/config/ca but vault-1.4.3 cannot sign using it. I haven't tried ed25519. Golang's ssh code (which vault uses) doesn't appear to know how to sign with ed25519 but should be able to sign with ecdsa. ...


3

It seems that Hashicorp itself offers an enterprise solution including 24x7 gold support called Hashicorp Vault premium enterprise.


3

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 ...


2

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.


1

As the Linux philosophy says: Make each program do one thing well So it's worth it to use the vault agent, cause it's doing well what it would be done. You can find an awesome example here


1

Developers or even admins of your GitHub repository wouldn't be able to see secrets configured there by default. Even if you debug GitHub Actions workflows and accidentally log secrets, GitHub would mark them with ***. So the only attack vector I can think of is highly deliberate and it would require modifying GitHub Actions workflow code and egressing the ...


1

You have your VAULT_ADDR set to HTTP, but vault is listening on TLS - the error you are receiving is the HTTP request receiving a TLS handshake. Try changing VAULT_ADDR to https://mydomain.com.


1

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 ...


1

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.


1

I think you're misunderstanding what is considered bad practice. Running vault with an in memory backend and being able to spin it up and provision it is fine. What is Not Fine is seeding the secrets in Vault from an insecure source. If you are just using Vault as a way to simplify operations, as opposed to a long term persistent state store - then go for ...


1

My choice would be design B. It's true that the availability of the Vault would be crucial, but Jenkins' availability would similarly be crucial in design A. So from this perspective the decision would normally be driven by the comparison of the two availability figures, if available. Based on its functionality I suspect that Jenkins is likely to be a more ...


1

According to this documentation, each vault has to be unsealed in a HA setup. Now you need to initializing and unsealing each Vault instance. # Initialize vault_s1 $ vault operator init # Unseal the vault_s1 $ vault operator unseal <unseal_key_1> $ vault operator unseal <unseal_key_2> $ vault operator unseal <unseal_key_3>


1

The simplest case is to use the Terraform Vault Provider (https://www.terraform.io/docs/providers/vault/index.html) - which, caveat, I've not used myself. Example from the Terraform site: provider "vault" { # It is strongly recommended to configure this provider through the # environment variables described above, so that each user can have # ...


1

In the hope of resurrecting this question, I will give my opinionated answer. As I understand it, the use of Vault is part of the drive to give more autonomy to teams, by removing fear of leaking or changing secrets. By providing somewhere to store and manage secrets, ops can give dev the means to continue developing at their own pace, following the ...


1

If you are unsure what happened, try deploying it in AWS via AWS vault quickstarts. They deploy vault end-to-end, so now you can compare it to yours and find out what was the problem.


1

I've ended up at exactly the same spot. We have a Vault server holding a good deal of secrets for different environments and various endpoints for each environment, so we set up kv engines for every environment and added a descriptive path for every secret. For instance, we have called our engines constant-text/environment/engine-name and all Database users ...


1

This mighty be a lengthy procedure but worth implementing, creating child tokens to fetch information from Vault Server. Execute following procedure at Vault Server. Create policy to restrict the access for clients. cat auth-policy.hcl path "secret/*" { capabilities = ["read"] } Write the policy vault policy write client-access ...


1

One thing you should know is, even though you can backup vault(consul, if you are using one as backend), you cannot restore to a new vault installation (if you loose the existing one). You can just restore to the original one.


1

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.


1

According to this documentation two vault servers have to be run. One of them has to be active and the other passive. In order to run such a setup both vault servers need to be unsealed.


1

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. https://github.com/jenkinsci/hashicorp-vault-plugin If one uses Jenkins pipelines, then one could replace the keyId with the one that is defined in Hashicorp vault. node { // define ...


Only top voted, non community-wiki answers of a minimum length are eligible