I had the same response. In fact, I assumed that there must be some kind of client-side secret wrapping with a customer-managed key or similar (i.e. you end up managing one secret, rather than n). I still need to secure access to the Doppler API key in any case.
Then I looked at the API documentation and it seems, no, you're being encouraged to send your secrets verbatim over the Internet.
I understand how this invites comparisons with the CSP secrets management products (e.g. AWS Secrets Manager), but it seems strictly worse from a number of perspectives:
* blast radius: if I'm a multi-cloud, or hybrid-cloud, property then compromise of one environment doesn't necessarily lead to compromise of the others; if I have all my eggs in one basket, like Doppler, then it seems like it does.
* Internet traversal: if I'm using something like AWS Secrets Manager from within AWS, I can entirely avoid having to traverse the Internet for my secrets by using VPC endpoints. Having to cross the Internet just means I'm exposed to more bad actors, an increased variety of attacks and also operational risk factors unrelated to security.
* (probable/possible?) segregation of duties concerns: the design of products like AWS Secrets Manager means that some kind of active collusion across product teams within AWS is required to create inappropriate disclosures and to conceal that disclosure. If secrets management is the only product line, that seems less likely to be sustainable.
I came here to find/make this comment - especially with secrets management, I don't want to rely on an external vendor being up to access/manage my secrets. I want full access.
License the software, let me deploy and manage it.
That completely changes the kind of software that is being built, and would be a radical departure to their cloud based solution. Where do you store your secrets? AWS? GCP?
They'd get stored wherever is appropriate given what we already depend on to deploy software. If we deploy to our own data centre, that's where the secrets would go. If we're deploying to AWS, that's where the secrets would go.
Yes, for secrets storage it either needs to be e2e encrypted, or self-hosted. E2e partly to protect against internal employee theft, and partly to protect against Doppler’s db getting pwned by malicious hackers, as is so common these days. Storing secrets in the cloud unencrypted is kinda crazy these days.
We realize that storing secrets requires trust and for some companies it may be outside of their comfort zone at the moment. We are currently focused on creating a super easy to use solution. An analogy: there are open source versions of Dropbox for users that don't trust Dropbox with their files (NextCloud, ownCloud, etc.), however this comes with the friction of having to host your own solution. We are more like Dropbox, where we want to create a solution that is incredibly easy to install, manage, and work with. That being said, a self-hosted solution is top of our mind as we totally acknowledge that some companies would not want to use a hosted solution.
just thinking out loud.. isn't it a better solution if you implement e2e encryption with dashboard and cli like how password managers do? i mean it's secrets and as a company you also wouldn't want to get into any trouble. if user losses the password he can always disable old keys of respective services and generate new ones.
Not completely, that’s why most of those also have self-hosted solutions available.
It is different in at least one important way: secrets (Such as private keys) are used to secure things (Such as code, data, or conversations) and thus are usually given a higher security priority (Like much tighter access control).
How does it fair against Vault? Vault is self hosted and open source.
Does everyone in this thread know the founder or something? No one is asking these and they're in my view the absolutely most important questions.