[oneplane]

> It's not just "can't have this secret in VCS or viewable via kubectl".

That is exactly what it is.

You seem to misunderstand (and thus downvote?) the statement I made. I'm not saying "haha vault bad", I'm answering "what other product" (from ghshephard) with the reality of today.

This has nothing to do with what Vault is or isn't, but just with the concept of storing secrets in a uniform way in clouds for use with cloud workloads what is being used right now.

[Alupis]

I did not downvote you, no. Downvoting because we disagree isn't how that's supposed to work, even though some use it that way.

Regardless, the use of Vault is not exclusive to cloud environments.

All of the listed features of Vault have benefits within larger organizations even if they don't use the "cloud" and deploy monolithic applications.

Most frameworks have built in ways to fetch secrets/config from Vault, making it an easy standardized way to do things across all of your applications/teams.

It doesn't mean you need to use it, of course, but it has a lot of perks for many different situations.

[oneplane]

I totally agree that Vault is more than a glorified password manager (because that's what most Clouds have in their implementation of a secrets store), but the thing is, everywhere I go, I don't see people use Vault, I see them use whatever AWS/Google/Azure happens to have (and often badly).

I'm not sure if that's even what ghshephard meant when he was curious for 'products', since technically all those cloud-integrated services aren't really stand-alone products for that matter.

In AWS for example, with or without EKS (and then something like External Secrets Operator in the EKS case), it's all just AWS Secrets Manager and sometimes Parameter Store. In a few cases people do manual encryption (using KMS), but in no case was HashiCorp Vault used.

Often, it's even worse: no secrets management at all. Stuff just gets pumped into environment variables (more often than not they get committed as .env files to Git), and there's just no drive to change that, even when a business policy is in place. Some even 'work around' this by storing secrets in password managers like 1Password and LastPass so they can check the compliance box without actually protecting the secrets (since they also live in plain text in VCS and at runtime in the environment).

In terms of 'products', I'd say Vault and the cloud ones don't really compare, but reality is depressing and secrets are often not as secret as the name implies. From a developer perspective, they might compare them because they desire the secrets to be injected into the environment either way, and as such the source doesn't matter much. I'm not sure if we should see that as a feature or a bug.

[ghshephard]

We use vault as a framework that associates authentication with secret engines via a policy framework. The Secret Engines could be AWS, PostGres Database, PKI, SSH Certificate Signer, Key value stores, etc... and the Authentication Framework might be LDAP, OKTA, or plain tokens. The Policy framework is pretty dynamic and has many thousands of possible policies mapping various authenticated entities to various authority (read, list, write, etc...) to various secret engines. Combine that with the syntactic niceties of template-rendering integration with the chosen secret-store, and maybe some clever stuff around single-use token wrapping - and I think of all of those features as belonging to a single product.

I'm relatively new to this field - and see tons of Vault at colleagues companies, and have friends who run/support Conjur (Enterprise more than cloud). Those are the only two secret-management framework/products I'd hear of - so was interesting in knowing what else had mindshare.

[oneplane]

I wonder if some of this also depends on how the secrets are consumed (and created), I'd imagine that if you store things like an API key and secret for a third party API, someone needs to 'enter' that data at some point in time and then set an ACL to allow a person or system to then consume it.

But if you have two programs what exchange secrets between multiple instances of each other, (one can do CRUD, the other only Read), you'd have much more interaction. Same as with a system creating secrets and a human reading it.

As for where it would make no sense at all: automated workload identities where you get time-limited temporary credentials that represent a role; most public clouds have some sort of link-local API, an injection method or mount method to provide ever-rotating secrets which gets picked up by the client SDK automatically. If you are using something like AWS, you'd be able to consume hundreds of services without ever persisting a secret anywhere.

This is also where my 'cloud' (and K8s) remarks are based on; when your workload and your resources speak the same authn/authz with a centrally coordinated policy system, there really isn't much value in adding something in the middle of that, and as such you don't see a lot of Vault and Vault-like implementations.

That said, as soon as you add something disconnected like local virtual machines, on-prem stuff etc. where authentication has historically been extremely bad and unless you brought a proper Kerberos setup you're screwed beyond mitigation. That's where Vault (when it came out) delivered a lot of value. It's probably also why we see AWS, IBM, GCP, Azure, in the same list with Vault and CyberArk. I'm surprised VMware doesn't have anything yet, but perhaps they recognise they lost this one already.