Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HashiCorp and Google: easing secret and infrastructure management

cloudplatform.googleblog.com

Post reply on HN
Print view View original

41–50 of 78 posts

Re: HashiCorp and Google: easing secret and infrastructure management

#41

Post by Johnny555 »

ams6110 wrote: post #39
thinkmassive wrote: post #37

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

Even if you do put a plaintext password into ansible.cfg, encrypting secrets in the playbook is still worthwhile so you don't commit them to your source code repository or accidentally share the secrets with the world when you publish your playbooks.

Re: HashiCorp and Google: easing secret and infrastructure management

#42

Post by zimbatm »

scrollaway wrote: post #7

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.

git-crypt[1] is quite handy in cases where the credentials have to live along the code. It's a nice improvement over having credentials in clear in a git repo and relatively easy to implement.

[1]: https://www.agwa.name/projects/git-crypt/

Re: HashiCorp and Google: easing secret and infrastructure management

#43

Post by manigandham »

All of the major clouds already have good secrets management built in. We have a simple library that uses Google's Key Management Service in a standalone project to encrypt/decrypt files held in a private storage bucket. Access to keys and files are controlled by service account roles. Seamless, efficient, no-ops model with built-in auditing and fine-grained control that works everywhere.

Re: HashiCorp and Google: easing secret and infrastructure management

#44

Post by arianvanp »

It's not really clear for me from the docs. But can you now use kubernetes secrets to not be stored in etcd but in vault? Or is just the token retrieval part fixed? The docs are a bit terse and don't mention much stuff on how you'd actually use it.

If I create a kubernetes secret will it be stored in vault if I set some magic switch? Or are we not there yet?

Re: HashiCorp and Google: easing secret and infrastructure management

#45

Post by manigandham »

outoftacos wrote: post #2

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

Any two corporations can work together to create partnerships and better integrations of their products and services. This is how most business is done.

What exactly is your problem?

Re: HashiCorp and Google: easing secret and infrastructure management

#46

Post by jaxxstorm »

arianvanp wrote: post #44

It's not really clear for me from the docs. But can you now use kubernetes secrets to not be stored in etcd but in vault? Or is just the token retrieval part fixed? The docs are a bit terse and don't mention much stuff on how you'd actually use it. If I create a kubernetes secret will it be stored in vault if I set some magic switch? Or are we not there yet?

Not there yet. You can store secrets in Vault, and now a kubernetes pod can authenticate against Vault which will allow it to retrieve secrets. If you're running your app in k8s, your app will be able to use the configured token to get to vault.

Re: HashiCorp and Google: easing secret and infrastructure management

#47

Post by jaxxstorm »

ejcx wrote: post #16
scrollaway wrote: post #7

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.

I almost never heard anything negative about vault until I did a presentation on all the troubles I had with it. Here are the slides about the issues I had: https://docs.google.com/presentation/d/1ipP2eB9pW5j3WDvzCGz9... At the end of the day, Vault gives you secret keys to manage which makes automating the unsealing process not fun if you want full automation. Talking with Armon from Hashicorp they planned to work o…

I wrote a tool to ease this: https://github.com/jaxxstorm/unseal it's not perfect, but it makes the process much, much easier

Re: HashiCorp and Google: easing secret and infrastructure management

#48

Post by jaxxstorm »

gobengo wrote: post #9
scrollaway wrote: post #7

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.

Hesitant why? It's pretty darned good. Kubernetes also has a Secret abstraction, but you probably don't want to start setting up Kubernetes just for secret storage. Vault is good at that.

kubernetes "secrets" are base64 encoded only, anyone with access to the resource can view the original secret.

Re: HashiCorp and Google: easing secret and infrastructure management

#49

Post by linsomniac »

ams6110 wrote: post #39
thinkmassive wrote: post #37

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

The parent's recommendation was to put a filename into the ansible.cfg, and that file could contain either the password, or a script that is then run which prints the password to stdout. For example, we have the script pull the password from a gpg-encrypted file.

Re: HashiCorp and Google: easing secret and infrastructure management

#50

Post by linsomniac »

Johnny555 wrote: post #12
scrollaway wrote: post #7

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.

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

We also use Ansible Vaults extensively and they work great.

Oddly enough though, I recently tried AWX (the open sourced Ansible Tower), and it wouldn't decrypt our vaults when trying to get the inventory, even though I gave it vault credentials (there was nowhere to associate it with the inventory run though).

So, we are still using RunDeck for a web UI/scheduling/web triggers/Slack integration of our Ansible runs.

Post reply on HN