3 ms·
The stub secrets client is just a key->value API, so the value of a proxy is pretty limited. It's not a hard enough problem that anyone is interested in having
by cbsmith 2y ago
The stub secrets client is just a key->value API, so the value of a proxy is pretty limited. It's not a hard enough problem that anyone is interested in having a separate product for it.
- derefr 2y agoThe point of the proxy, is that it would talk to these fifteen different backends and convert them into a generic key-value API. And also, as with the AWS solution above, do TTL-based cache refresh of the secrets, cache-invalidation when it loses connection to the backend, etc. Also, the "stub" client wouldn't really be a stub, as all the "ambient environment" secrets adapters would necessarily be local to the client rather than to the proxy. The client library would be a bit like using dnsmasq(1) as a local "stub" DNS resolver — where it reads your /etc/hosts and so forth, but for most things is deferring to a configured upstream DNS server.
- abadpoli 2y agoThe extent of the “conversion” required would pretty much just be taking one form of JSON output and transforming it into a different JSON output, which is pretty easy to do in a few lines of Python or a single jq command. It would likely be more work and hassle to have to install and manage a secrets proxy, rather than just writing a few transformation lines, or better yet just using the SDK of the service you’re using. Even this secrets manager proxy that the OP is about is explicitly to be used in legacy situations where you can’t use the AWS SDK, which is preferred because it does all of the stuff you mentioned for you. However, this is Hacker News! If you think you see a problem that can be solved that other people don’t, why don’t you build it?
- cbsmith 2y agoI mean, that's kind of what KeyWhiz does, no?