3 ms·

Based on my limited experience Vault is actually becoming a niche tool. Big cloud players have been offering more limited solutions that are good enough for man

Based on my limited experience Vault is actually becoming a niche tool. Big cloud players have been offering more limited solutions that are good enough for many if not most use cases. A few years ago as a consultant I'd unconditionally recommend Vault to my clients. If I were consulting today, I'd first ask what are they missing from KMS and Secrets Manager.

fud101 3y ago
KMS? Secrets manager? Are those offered by a particular vendor or what
- Aeolun 3y ago
  Yeah, they’re AWS secrets management services.
  - fishnchips 3y ago
    Yes, these two are AWS terms, but other clouds have nearly the same services, and often called the same, too.
- imglorp 3y ago
  Yes but if you want to be multi-cloud and not have to integrate with each cloud's secret storage API, you would do it once for Vault and bring it with you to each cloud.
  - xyzzy123 3y ago
    Probably I just work at more dysfunctional places than you, but: If I'm building product for on prem I'd prefer to use env vars or k8s secrets and let the customer integrate their preferred secrets manager. Also helpful when you run sales POCs where ease of getting to splash page really matters. Building inside enterprise, I've never actually had to support multiple clouds for the same component but if it ever comes up and I have any sort of choice in the matter I would probably rather template 3 native secrets integrations than deal with the special circle of hell that is enterprise-managed Vault or CyberArk.
  - prmoustache 3y ago
    The reality is you will never use a common secret storage anyway as usually and even when using multi-cloud tools like terraform you write a lot of cloud vendor specific stuff because they do not share the same provider. So using different secret storage API is not a huge deal and pretty much a moot point. Also my vision of multi-cloud in large org hasn't been that a particular product/app or team was ever using multiple clouds. My experience is that large orgs like to have multi-cloud support because they grow by acquiring other companies regardless of which cloud vendor they are using so you just want to provide standards and templates for everyone. Obviously said templates will be usually cloud vendor specifics.
  - fishnchips 3y ago
    Even when going multi-cloud you can employ different strategies. Vault is definitely one of them, but you can also use federation to exchange one cloud's credentials for another's, giving you the ability to centralize secrets in one of them. You can use a layer of abstraction like GoCloud [0]. You can also build for each cloud separately and decide either not to centralize secrets at all, or build some trivial bespoke tooling to synchronize some of them. I'm not endorsing any of the options, nor am I trying to argue that Vault is never the right choice, I'm just pointing out that Vault isn't the only viable alternative. https://github.com/google/go-cloud https://github.com/google/go-cloud

fud101 3y ago

KMS? Secrets manager? Are those offered by a particular vendor or what

Aeolun 3y ago
Yeah, they’re AWS secrets management services.
- fishnchips 3y ago
  Yes, these two are AWS terms, but other clouds have nearly the same services, and often called the same, too.
imglorp 3y ago
Yes but if you want to be multi-cloud and not have to integrate with each cloud's secret storage API, you would do it once for Vault and bring it with you to each cloud.
- xyzzy123 3y ago
  Probably I just work at more dysfunctional places than you, but: If I'm building product for on prem I'd prefer to use env vars or k8s secrets and let the customer integrate their preferred secrets manager. Also helpful when you run sales POCs where ease of getting to splash page really matters. Building inside enterprise, I've never actually had to support multiple clouds for the same component but if it ever comes up and I have any sort of choice in the matter I would probably rather template 3 native secrets integrations than deal with the special circle of hell that is enterprise-managed Vault or CyberArk.
- prmoustache 3y ago
  The reality is you will never use a common secret storage anyway as usually and even when using multi-cloud tools like terraform you write a lot of cloud vendor specific stuff because they do not share the same provider. So using different secret storage API is not a huge deal and pretty much a moot point. Also my vision of multi-cloud in large org hasn't been that a particular product/app or team was ever using multiple clouds. My experience is that large orgs like to have multi-cloud support because they grow by acquiring other companies regardless of which cloud vendor they are using so you just want to provide standards and templates for everyone. Obviously said templates will be usually cloud vendor specifics.
- fishnchips 3y ago
  Even when going multi-cloud you can employ different strategies. Vault is definitely one of them, but you can also use federation to exchange one cloud's credentials for another's, giving you the ability to centralize secrets in one of them. You can use a layer of abstraction like GoCloud [0]. You can also build for each cloud separately and decide either not to centralize secrets at all, or build some trivial bespoke tooling to synchronize some of them. I'm not endorsing any of the options, nor am I trying to argue that Vault is never the right choice, I'm just pointing out that Vault isn't the only viable alternative. https://github.com/google/go-cloud https://github.com/google/go-cloud