Check out the Secretless Broker at https://secretless.io. It's a cool open source project that allows applications to not need to know secrets which adheres to 12-factor app guidelines.
hmmm.... im trying to understand the benefit of secretless broker... if someone compromises thisnwouldnt they have access to all credentials for everything?
now we are just moving from trusting a bunch of distinct services to trusting this single broker... just moving the responsibility of trust to a single point of potential failure no?
Also dont credentials have to be passed to secretless broker? how does it know the application has access to the service? isnt that still at risk of being leaked.
i like the idea of not thinking about secrets but it seems to good to be true.
I developed go-keyconfig after realizing that almost every CLI that I use on a daily basis that requires authentication of some kind drops the secrets in a local filesystem config file in plain-text. As one could imagine, this is ripe for an accidental git commit or easy reading from an attacker.
Every OS comes with a secrets manager of some kind... MacOS has OSX Keychain, Linux has GNOME Keyring, KWallet, and secret-service, even Windows has Credential Manager.
This module is designed to help developers creating apps or CLIs needing to store configuration values in config files a secure means of doing so. It supports All the secret managers mentioned above.
I would love to hear everyone's feedback and thoughts!
The similarities with VPA/Alero end at the concept of QR-based login. It is a system for provisioning enterprise vendors and requires a substantial onboarding process. It is not an SDK for integration into consumer-facing / third-party applications.
Can't speak for how it works on the back end (though it clearly works differently from Keyri given VPA's QR code contains much more data and is therefore slower / more unreliable to scan). In terms of security on the front end, VPA is phishable as explained in earlier comment threads.
It's one of my least favourite things about vault as a product - it would have been technically feasible to not require unsealing for read-only operations, and thus not made a 2am restart a critical failure. I made a PoC once (I don't think it's still published anywhere) that does exactly this. Unfortunately they chose not to do this.
Admittedly simplicity is a feature in and of itself, and the read-only unsealing requires more complex asymmetric cryptography, but the excellent nacl[0] makes this a lot easier than it used to be.
I kid you not, the main reason we haven't implemented vault yet, is not because we're worried about security. It's because we're deathly afraid of locking ourselves out by making a mistake, taking the whole system down.
Meaning, this makes Vault more of a "let's really dedicate time to think of every possible scenario" type implementation rather than "let's just keep adding a couple of secrets a week".
It is possible to control both the number of key shares and the threshold required to unseal Vault (and now to do automatic unseal too), so I’m not certain this particular condition should be too much of a concern anymore. That said, considering as many scenarios as possible is definitely sensible!
I really do not understand your frustration. We are running 5 node cluster in production with the keepalived and nobody needs to wake up unsealing if one, or two instances fail. Perfectly good to do it in the morning by copy pasting curl oneliner from the keepass.
