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

51–60 of 78 posts

Re: HashiCorp and Google: easing secret and infrastructure management

#51

Post by arianvanp »

jaxxstorm wrote: post #46
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.

Thanks. But it seems like a good first step into the right direction!

Re: HashiCorp and Google: easing secret and infrastructure management

#52

Post by dasil003 »

manigandham wrote: post #43

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.

Within a single cloud that provides every single service you need.

Re: HashiCorp and Google: easing secret and infrastructure management

#53

Post by true_tuna »

manigandham wrote: post #43

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.

This sounds way simpler and 10x better than what most organizations do (secrets in virsion control, secrets on local file system or environment variables). Do you mind doing a quick how-to? It could probably help 90% of organizations take a step towards better security.

Re: HashiCorp and Google: easing secret and infrastructure management

#54

Post by manigandham »

dasil003 wrote: post #52
manigandham wrote: post #43

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.

Within a single cloud that provides every single service you need.

As stated, this works everywhere, whether on premise or inside a cloud provider. Key management and storage have public APIs, the only thing you need to access them is a service account key file which authorizes everything else.

Service accounts are necessary to run anything in GCP anyway but can be used externally (like the gcloud CLI on your desktop) or a similar setup specific to AWS or Azure if that's your primary provider.

Re: HashiCorp and Google: easing secret and infrastructure management

#55

Post by kaishiro »

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.

Responding not so much with a solution but with a question. We currently encrypt files in place with gpg (secretKeys.json => secretKeys.json.encrypted) and have the source file (secretKeys.json) git ignored while the derivative file is just added to the repo.

This is admittedly a bit low tech, but could someone more well versed than me tell me what's wrong with this setup.

Re: HashiCorp and Google: easing secret and infrastructure management

#56

Post by kaishiro »

rraval wrote: post #21
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.

We use StackExchange's blackbox [1] to check in GPG encrypted secrets into our monorepo (contains both ansible deployment playbooks and the code itself). This way, we can introduce secrets and the code that uses it in a single commit! [1] https://github.com/StackExchange/blackbox

Ah, wish I would have seen this before commenting upstream. Will definitely give this a look.

Re: HashiCorp and Google: easing secret and infrastructure management

#57

Post by dasil003 »

manigandham wrote: post #54
dasil003 wrote: post #52

Earlier quoted context omitted.

Within a single cloud that provides every single service you need.

As stated, this works everywhere, whether on premise or inside a cloud provider. Key management and storage have public APIs, the only thing you need to access them is a service account key file which authorizes everything else. Service accounts are necessary to run anything in GCP anyway but can be used externally (like the gcloud CLI on your desktop) or a similar setup specific to AWS or Azure if that's your primar…

Sorry I misread what you are saying, yes that is a nice basic setup, as the other reply mentions, better than what most orgs start with. That said, I don't think you should be so quick to poo-poo Vault as it provides a lot of very nice things in a fairly flexible package.

Re: HashiCorp and Google: easing secret and infrastructure management

#58

Post by czbond »

kaishiro wrote: post #55
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.

Responding not so much with a solution but with a question. We currently encrypt files in place with gpg (secretKeys.json => secretKeys.json.encrypted) and have the source file (secretKeys.json) git ignored while the derivative file is just added to the repo. This is admittedly a bit low tech, but could someone more well versed than me tell me what's wrong with this setup.

Then as part of your code or deployment, your private key is on a server and some process decrypts it? It is low tech, but a good solution. Only concern would be how that private key is stored, and if it could be compromised. (edited)

Re: HashiCorp and Google: easing secret and infrastructure management

#59

Post by matburt »

linsomniac wrote: post #50
Johnny555 wrote: post #12

Earlier 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

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.

developer of AWX here. We're working on this! unvaulting is available during playbook runs but we definitely need to make it available during inventory syncs also. The features coming up in Ansible 2.4 will enable us to do this.

Re: HashiCorp and Google: easing secret and infrastructure management

#60

Post by kaishiro »

czbond wrote: post #58
kaishiro wrote: post #55

Earlier quoted context omitted.

Responding not so much with a solution but with a question. We currently encrypt files in place with gpg (secretKeys.json => secretKeys.json.encrypted) and have the source file (secretKeys.json) git ignored while the derivative file is just added to the repo. This is admittedly a bit low tech, but could someone more well versed than me tell me what's wrong with this setup.

Then as part of your code or deployment, your private key is on a server and some process decrypts it? It is low tech, but a good solution. Only concern would be how that private key is stored, and if it could be compromised. (edited)

Thanks czbond. And yeah, that's precisely the setup. Appreciate the response.
Post reply on HN