What do people here use to store and source-control secrets/almost-secrets and make them available to (pick n) terraform/ansible/salt/chef/...? I've heard a lot of good things of Hashicorp Vault ( https://www.vaultproject.io ) but been hesitant to go with it.
HashiCorp and Google: easing secret and infrastructure management
31–40 of 78 posts
Re: HashiCorp and Google: easing secret and infrastructure management
#32I worry a lot about how these megacorps will treat "collaborators" vs "non collaborators" in the coming years. Obviously you can't just outright buy everyone, but they seem to be increasingly abusive towards technologies and teams that aren't on board with their interests and ideology. Actually I'm more worried about how Facebook and Amazon treat non compliance, but Google sure seems to be getting shadier every day.…
Tinfoilism does not help anything. This is a genuine collaboration effort by two of the players whose services many people are already using together, and they are making that experience better for their users. The kind of dismissiveness and hyperbole in your comment is why we can't have nice things.
The reason we can't have nice has much more to do with naivete than paranoia when the paranoics are right.
Re: HashiCorp and Google: easing secret and infrastructure management
#33What do people here use to store and source-control secrets/almost-secrets and make them available to (pick n) terraform/ansible/salt/chef/...? I've heard a lot of good things of Hashicorp Vault ( https://www.vaultproject.io ) but been hesitant to go with it.
We're on AWS so we use SSM Parameter Store. Works nicely with KMS and IAM.
Re: HashiCorp and Google: easing secret and infrastructure management
#34Earlier quoted context omitted.
Can't recommend Vault enough. By far the easiest and most capable solution to work with. The only downside I can point out is that the multi-cluster/region HA requires expensive enterprise licensing, but that is something most user cases don't require.
Did you use it with Kubernetes by any chance?
Re: HashiCorp and Google: easing secret and infrastructure management
#35Earlier quoted context omitted.
Can't recommend Vault enough. By far the easiest and most capable solution to work with. The only downside I can point out is that the multi-cluster/region HA requires expensive enterprise licensing, but that is something most user cases don't require.
> By far the easiest Secret management is as complex as the system which relies upon it. Vault is not as easy as many other tools designed for simple systems. GPG by itself is often enough to manage secrets. There are probably 40 or more secret management solutions out there, many tailored for specific uses. Most CMS's have their own secret management baked in. Most orchestration and infrastructure tools do too. Four…
Take the database secret backend for example. Getting that same feature out of other simple systems, would be a lot of work. Audit trails are another low effort high reward feature. When you start to get into combining those features, it is an even greater pay off. When you start to take into consideration HA clusters...well if you want to put that together on your own have at it.
Much of "easiest" has to do with familiarity as well. I've seen new users get Vault up in minutes that still don't have GPG setup "cause it is hard". If you are already working with DynamoDB or Consul, you already know how to setup the storage. Those are common skills. I'm sure there are folks that fall on the other side of that use GPG often, but it doesn't make either side more objectively easy.
If you only have the need for a simple system, then Vault may be overkill. I would say Vault is comparable to Kubernetes. Does everyone need it: No. Simpler stuff can be done with config management or tools like Nomad. Does it have features that most people will eventually want to use: Absolutely.
Secret management is one of those things were simple solutions end up easily becoming more and more involved just like container orchestration. Especially when you get into chicken/egg scenarios regarding stuff like some of the tools you mentioned.
Side note: I've tried at least 12 other tools for this purpose , and I would recommend Vault over all of them for most every scenario that is more involved then "Use 1Password".
Re: HashiCorp and Google: easing secret and infrastructure management
#36Earlier quoted context omitted.
Tinfoilism does not help anything. This is a genuine collaboration effort by two of the players whose services many people are already using together, and they are making that experience better for their users. The kind of dismissiveness and hyperbole in your comment is why we can't have nice things.
It's not "Tinfoilism" in a post-Snowden world, okay? The reason we can't have nice has much more to do with naivete than paranoia when the paranoics are right.
You say this is not tinfoilism, but the tinfoil in this one is strong.
Re: HashiCorp and Google: easing secret and infrastructure management
#37What do people here use to store and source-control secrets/almost-secrets and make them available to (pick n) terraform/ansible/salt/chef/...? I've heard a lot of good things of Hashicorp Vault ( https://www.vaultproject.io ) but been hesitant to go with it.
Another option for Ansible is Ansible Vault (which is not related to Hashicorp Vault) -- you can use it to password protect secrets used for playbooks (you need to supply the password when you run the playbook). https://docs.ansible.com/ansible/latest/playbooks_vault.html
You can also specify vault-password-file in ansible.cfg [1] It can be a shell script rather than plaintext, so you can use it to call the CLI password manager "pass"[2] for instance. This is handy for automation.
[1] http://docs.ansible.com/ansible/latest/intro_configuration.h... [2] https://www.passwordstore.org/
Re: HashiCorp and Google: easing secret and infrastructure management
#38Earlier quoted context omitted.
It's not "Tinfoilism" in a post-Snowden world, okay? The reason we can't have nice has much more to do with naivete than paranoia when the paranoics are right.
How does Snowden have anything to do with a collaboration between Google and Hashicorp? You say this is not tinfoilism, but the tinfoil in this one is strong.
I don't think they have anything to do with each other. My point is that we know some weird things are happening and it's a put-down and a conversation stopper to call someone a tinfoil hat wearer.
(The best you can say is that the person you're insulting might have a mental illness.)
This is a pet peeve of mine because I knew about some of the hijinks that have gone down (and are going down) since before Snowden flushed his life down the toilet to get people to pay attention and I've been dismissed with that exact term. It's naive in a post-Snowden world to not postulate conspiracies.
Re: HashiCorp and Google: easing secret and infrastructure management
#39Earlier quoted context omitted.
Another option for Ansible is Ansible Vault (which is not related to Hashicorp Vault) -- you can use it to password protect secrets used for playbooks (you need to supply the password when you run the playbook). https://docs.ansible.com/ansible/latest/playbooks_vault.html
> you need to supply the password when you run the playbook You can also specify vault-password-file in ansible.cfg [1] It can be a shell script rather than plaintext, so you can use it to call the CLI password manager "pass"[2] for instance. This is handy for automation. [1] http://docs.ansible.com/ansible/latest/intro_configuration.h... [2] https://www.passwordstore.org/
Re: HashiCorp and Google: easing secret and infrastructure management
#40Earlier quoted context omitted.
> you need to supply the password when you run the playbook You can also specify vault-password-file in ansible.cfg [1] It can be a shell script rather than plaintext, so you can use it to call the CLI password manager "pass"[2] for instance. This is handy for automation. [1] http://docs.ansible.com/ansible/latest/intro_configuration.h... [2] https://www.passwordstore.org/
Of course if you're putting the encryption password in ansible.cfg you might as well just leave the original file unencrypted.