8 ms·

HashiCorp and Google: easing secret and infrastructure management

295 points by rey12rey 9y ago

outoftacos 9y ago
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. This combined with the W3C evolving into a corrupt entity just makes me want to get out of tech completely. Maybe if I could get some awesome dev job at the EFF?
- deleted 9y ago
  [deleted]
- navaati 9y ago
  From what I can tell, this is all opensource using their publicly documented API. That is, you could implement the same support for GCP in your own auth backend product, and you could implement the same support for your own cloud platform in Vault. So… I don't really get what you're talking about in this context.
  - tyingq 9y ago
    "We're working to enhance the integration between HashiCorp Vault and GCP, including Vault authentication backends for IAM and signed VM metadata." There's not much detail in that. But, you could certainly read it in a way that using Hashicorp products might be lower friction than using other products on GCP.
- kbenson 9y ago
  > 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. I 'm not sure where you're coming from or going with this. Do you have an example to illustrate? What are you considering collaborators and non-collaborators?
- lmickh 9y ago
  The Hashicorp stack is pretty widely used in part for its open source cross-platform capabilities. This seems more along the lines of "Hey! You already use Terraform/Vault for provider X. Now GCP works even better with the tools you already use!" You concern is probably worthwhile, but I think this is not an example of it.
- halfteatree 9y ago
  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.
  - carapace 9y ago
    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.
    - halfteatree 9y ago
      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.
      - carapace 9y ago
        > How does Snowden have anything to do with a collaboration between Google and Hashicorp? 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.
- outoftacos 9y ago
  And the Googlers arrive right on cue, hahahaha
  - sctb 9y ago
    Could you please not do this? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- manigandham 9y ago
  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?
- jacques_chester 9y ago
  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.
scrollaway 9y ago
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 https://www.vaultproject.io) but been hesitant to go with it.
- gobengo 9y ago
  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.
  - jaxxstorm 9y ago
    kubernetes "secrets" are base64 encoded only, anyone with access to the resource can view the original secret.
    - jesseendahl 9y ago
      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-data/ 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-data/#providers https://kubernetes.io/docs/tasks/administer-cluster/encrypt-...
- lmickh 9y ago
  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.
arianvanp 9y ago
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?
- jaxxstorm 9y ago
  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.
  - arianvanp 9y ago
    Thanks. But it seems like a good first step into the right direction!
manigandham 9y ago
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.
- dasil003 9y ago
  Within a single cloud that provides every single service you need.
  - manigandham 9y ago
    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.
    - dasil003 9y ago
      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.
      - manigandham 9y ago
        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.
- true_tuna 9y ago
  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.
yeukhon 9y ago
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 https://github.com/mozilla/sops
disordr 9y ago
The AWS EC2 Systems Manager Service and the Parameter store: https://aws.amazon.com/ec2/systems-manager/parameter-store/ https://aws.amazon.com/ec2/systems-manager/parameter-store/ is a great way to store secrets with integrated encryption provided by KMS.

295 points by rey12rey 9y ago

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. This combined with the W3C evolving into a corrupt entity just makes me want to get out of tech completely. Maybe if I could get some awesome dev job at the EFF?

deleted 9y ago
[deleted]
navaati 9y ago
From what I can tell, this is all opensource using their publicly documented API. That is, you could implement the same support for GCP in your own auth backend product, and you could implement the same support for your own cloud platform in Vault. So… I don't really get what you're talking about in this context.
- tyingq 9y ago
  "We're working to enhance the integration between HashiCorp Vault and GCP, including Vault authentication backends for IAM and signed VM metadata." There's not much detail in that. But, you could certainly read it in a way that using Hashicorp products might be lower friction than using other products on GCP.
kbenson 9y ago
> 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. I 'm not sure where you're coming from or going with this. Do you have an example to illustrate? What are you considering collaborators and non-collaborators?
lmickh 9y ago
The Hashicorp stack is pretty widely used in part for its open source cross-platform capabilities. This seems more along the lines of "Hey! You already use Terraform/Vault for provider X. Now GCP works even better with the tools you already use!" You concern is probably worthwhile, but I think this is not an example of it.
halfteatree 9y ago
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.
- carapace 9y ago
  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.
  - halfteatree 9y ago
    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.
    - carapace 9y ago
      > How does Snowden have anything to do with a collaboration between Google and Hashicorp? 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.
outoftacos 9y ago
And the Googlers arrive right on cue, hahahaha
- sctb 9y ago
  Could you please not do this? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
manigandham 9y ago
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?
jacques_chester 9y ago
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.

scrollaway 9y ago

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 https://www.vaultproject.io) but been hesitant to go with it.

gobengo 9y ago
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.
- jaxxstorm 9y ago
  kubernetes "secrets" are base64 encoded only, anyone with access to the resource can view the original secret.
  - jesseendahl 9y ago
    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-data/ 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-data/#providers https://kubernetes.io/docs/tasks/administer-cluster/encrypt-...
lmickh 9y ago
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.

arianvanp 9y ago

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?

jaxxstorm 9y ago
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.
- arianvanp 9y ago
  Thanks. But it seems like a good first step into the right direction!

manigandham 9y ago

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.

dasil003 9y ago
Within a single cloud that provides every single service you need.
- manigandham 9y ago
  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.
  - dasil003 9y ago
    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.
    - manigandham 9y ago
      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.
true_tuna 9y ago
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.

yeukhon 9y ago

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 https://github.com/mozilla/sops

disordr 9y ago

The AWS EC2 Systems Manager Service and the Parameter store: https://aws.amazon.com/ec2/systems-manager/parameter-store/ https://aws.amazon.com/ec2/systems-manager/parameter-store/ is a great way to store secrets with integrated encryption provided by KMS.