I'm a little confused about what problem this solves. According to the documentation, secrets are encrypted by each clients unique key, and the server only has a copy of the encrypted secret? So the sensitive data is essentially still on a single client: lose the keys and none of the secrets can be recovered?
I'll see if I can re-work the documentation a bit to make this clearer - I think in the hope of making it easy to understand I oversimplified a bit too much.
Each secret has a unique key generated for it on the machine uploading the secret. The unique key is also uploaded to the server, but encrypted (initially for super users and the owner only), and it's this unique key for the secret that's shared. This means that the server cannot read the secret (it never gets the decrypted key), but the secret can be shared with clients without having to maintain lots of copies of the secret itself (which could potentially be large).
The sharing mechanism is a bit involved, as it has to happen without any decryption on the server, but I'll try document this properly.
To get into a situation where secrets were unrecoverable, you'd have to lose all your super-user keys and all the admin/client keys with access.
Yeah, that makes a lot more sense ;-) (I actually even glanced at the source, but with the wrong idea from the docs, it wasn't immediately obvious that the server/users were able to access the plain-text keys -- which of course made the whole thing seem a little absurd).
Does sound like you've kind-a-sort-a reimplemented half of kerberos... I've been mulling the idea of doing that myself, leveraging NaCl, and maybe something simpler than DNS/ldap -- but I'm not convinced it makes sense. I suppose kerberos doesn't really offer any arbitrary access to key-values (that'd be eg ldap, and those aren't encrypted with only user-keys) -- so the ideas just overlap a bit, without one making the other redundant.
I've been looking to build something like this, but backed by ETCD. I've had the hardest time finding other implementations or even figuring out what to call such a system. Credential storage and management is hard, especially in a large environment.
You could easily store the client configs in etcd then just deploy the client with whatever bootstrapping you use if you wanted to go down that route.
As long as the client knows what it's called and where the server is, it doesn't need anything else - designed to be as simple and lightweight to deploy as possible.
