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

61–70 of 78 posts

Re: HashiCorp and Google: easing secret and infrastructure management

#61

Post by manigandham »

true_tuna wrote: post #53
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.

Google actually has a technical how-to here: https://cloud.google.com/kms/docs/store-secrets and in-depth solution architecture here: https://cloud.google.com/kms/docs/secret-management

Key Management Service creates and maintains private keys for you and provides an API to easily encrypt or decrypt some data. Basically call method KMS.Decrypt("name_of_key_to_use", ) and get back decrypted content. Secrets are simple text files encrypted with KMS and stored in a private storage bucket. For example we have something like "database-secrets.dev.json.encrypted".

We have a small library that took a day to write, used in all of our projects that does the following on startup: open private storage bucket, download encrypted file, call the KMS API, decrypt the file, and parse the raw contents as json. Now the app has the secrets in-memory to be used anywhere. No infrastructure required, nothing on disk and this is universally accessible whether inside Google cloud or on local machine. Takes under 1 second when running in the cloud.

I dont think I can do better than the documentation but let me know if you have any questions.

Re: HashiCorp and Google: easing secret and infrastructure management

#62

Post by bamboozled »

toomuchtodo wrote: post #18
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

Ansible Vault is the bees knees compared to Hashicorp Vault (if you're already using Ansible). Very pleasant to use, A++ would use again.

Same, love it !

Re: HashiCorp and Google: easing secret and infrastructure management

#63

Post by yeukhon »

Anything secret involves a master key. If you don't trust AWS, then you need to supply your own master key. But for most setup, IMO, you should just let AWS handle the key management, and you use role to decrypt. Rotation is a big deal though. For server, SSH key can be encrypted in KMS and we either completely replace the box, or we rotate one box at a time. For DB servers, it's important to choose a DB that can stream data to a new box with as little impact as possible (or allows replication). But these takes time to develop (I can't use container to host DB or critical applications because the network performance, at least a year ago).

BTW Mozilla's sops [1] is quite interesting. I've been testing this for a while now.

[1]: https://github.com/mozilla/sops

Re: HashiCorp and Google: easing secret and infrastructure management

#64

Post by corford »

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

Another happy Ansible Vault user here. It's simple and effective.

Re: HashiCorp and Google: easing secret and infrastructure management

#65

Post by jesseendahl »

jaxxstorm wrote: post #48
gobengo wrote: post #9

Earlier quoted context omitted.

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.

The lack of encryption at rest for Kubernetes secrets was one of the (many) factors in why we originally chose Vault.

That said, there's been a lot progress recently in this area recently. Starting in Kubernetes 1.7, you can optionally encrypt etcd at rest: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-...

You also have a few good choices for the crypto. Two of the choices are Secret Box (XSalsa20 + Poly1305) and AES-GCM with random nonce.

Full list of providers, including info on strength + other considerations:

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-...

Re: HashiCorp and Google: easing secret and infrastructure management

#66

Post by jacques_chester »

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

I work for Pivotal and we donate engineering for a product (CredHub) which is comparable to Vault, though with a slightly different set of motivating problems.

We, like HashiCorp, cooperate with Google on a lot of things.

They don't pick winners. What works best for Google is to get your workload into GCP. It matters little whether the bits you run are Pivotal bits, HashiCorp bits, Docker bits, Red Hat bits, IBM bits, Microsoft bits or your own bits.

What matters is that they're being processed on GCP atoms.

The analogy I have used before is that Shell, BP and ExxonMobil don't care whether you burn their fuel in a Ford or a Toyota. They mostly care that you burn their fuel.

I don't mean to paint a cynical picture here. As a partner Google is excellent, responsive and respectful, our engineering cultures have good compatibility and there are deep common interests. But Google's goal is to make GCP the most attractive place to run your workload. That means that they are going to be ecumenical. They want to help us to win, but they want to help everyone to win, because that helps them to win.

Re: HashiCorp and Google: easing secret and infrastructure management

#67

Post by linsomniac »

matburt wrote: post #59
linsomniac wrote: post #50

Earlier quoted context omitted.

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.

Are there any pointers on how to work around this?

I think a large part of our problem is that we are using Ganeti for most of our VMs, rather than something supported native by AWX like OpenStack/EC2/Azure. I have an inventory script we have been using, but couldn't get it to run in AWX due to AWS credentials not being made available in a way that boto recognized (the inventory is pulled both from Ganeti and EC2).

Re: HashiCorp and Google: easing secret and infrastructure management

#68

Post by manigandham »

dasil003 wrote: post #57
manigandham wrote: post #54

Earlier quoted context omitted.

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.

Didn't poo-poo Vault - just saying that there's a very good system already built in that involves wiring up just 2 API calls and integrates perfectly into the existing IAM security roles.

Re: HashiCorp and Google: easing secret and infrastructure management

#69

Post by hashmp »

manigandham wrote: post #61
true_tuna wrote: post #53

Earlier quoted context omitted.

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.

Google actually has a technical how-to here: https://cloud.google.com/kms/docs/store-secrets and in-depth solution architecture here: https://cloud.google.com/kms/docs/secret-management Key Management Service creates and maintains private keys for you and provides an API to easily encrypt or decrypt some data. Basically call method KMS.Decrypt("name_of_key_to_use", ) and get back decrypted content. Secrets are simple…

AWS offers a similar service for anyone interested.

https://aws.amazon.com/kms/

You can limit access to the keys based on IAM instance profiles. So that only certain instances can access specific credentials.

Post reply on HN