How Does Vault Compare to Cloud-Native KMS?
Jul 15, 2019
Learn about several specific advantages HashiCorp Vault has over cloud vendors' KMS and secrets management services.
Founder & Co-CTO, HashiCorp
Founder & Co-CTO, HashiCorp
Armon Dadgar: We often get asked, “Parts of Vault, some of the functionality exists as cloud-native capability. KMS, for example. How do you think about the difference between some of those cloud-native services, like KMS, and Vault and what it offers?
» Centralized security
Mitchell Hashimoto: There are a couple of ways. One is philosophical, and the philosophical approach is that Vault is centralized security, for a lot of security: It’s a key management system, it’s an encryption system, it’s a [PKI system](https://medium.com/hashicorp-engineering/pki-as-a-service-with-hashicorp-vault-a8d075ece9a “PKI as a service with HashiCorp Vault”), it’s secrets storage.
It does all these things in one box, and philosophically that’s important because we believe that it’s easier to secure and to have access control for one, central security solution than it is to repeat that best practice a dozen or more times. You’re more likely to do something right one time than to do it right multiple times. So with Vault, philosophically, we think you should focus on that.
» Run it anywhere
These cloud-native solutions are very much feature-oriented. You adopt one and another, and you mix and match. I think philosophically there’s that.
But then technically, they’re also cloud-specific usually. A big benefit of Vault is that it can run anywhere. It can run on your laptop, it can run on your on-prem data center, in the cloud, in any cloud provider basically.
So, a big reason to adopt Vault is to have control of that data, and most importantly be able to replicate it in other regions, other data centers, other cloud providers. That’s a feature that we provide with Vault.
» Identity brokering
Armon: I’ll add that you can deploy Vault in these different cloud environments. I think that also opens up a pretty useful use case around identity brokering, the notion of, What if I have an app that’s running on premises, but it needs to read and write from AWS S3; or an app running in Amazon, but it needs to read and write from Google’s Blob Storage; or some service in Google. My app running in Amazon, it gets an identity provided through IAM from Amazon, but that doesn’t mean anything to Google, doesn’t mean anything to Azure.
You need some sort of identity translation or brokering, and Vault can fill that role. You can log in and authenticate and say, “Hey, I’m a web server running on Amazon; here’s my IAM token. Now I’d like to get a Google credential that lets me read and write from Blob Storage.” So in that sense, because you can run Vault across all these sites, it can act as this translation broker. That native service can’t play the same role.
» Greater development velocity
Mitchell: I mentioned running Vault on your laptop. I think that’s a really big deal, because—in a runtime environment not so much, but from a development standpoint it’s really important. If you’re using a cloud-native service, you either have to have an internet connection, you have to have an account, a billing system set up so you can use stuff. If you’re doing something as simple as secrets storage, or even encryption, it’s a pretty big burden to have to set that up. With Vault you can just run it all locally in dev mode, and the API is there and you just hit it. I think that’s really valuable, from a development velocity standpoint.