proposal: secrets management

[bobheadxi]

Summary

We should be able to create and distribute credentials to subsets of Rocket users based on team.

Requirements

• Some sort of secret manager - either built-in to Rocket, or leveraging something like Vault. This would probably involve setting up our own Vault instance (or whatever service we opt to use)
  • alternative approaches include more consumer-facing password managers like Passbolt and Bitwarden, but I don't think those are geared for programmatic access like Vault is (ie they have APIs, but seemingly not for reading passwords, likely for good reason)
• /rocket secret [create|view|delete|edit] $SECRET for secrets CRUD
  • what secrets looks like (structured vs unstructured) probably depends on the backend, but I would be in favour of unstructured and encourage JSON secrets/arbitrary format as plain text
• /rocket secret [grant|rescind] $SECRET $TEAM for providing access

Context

Suggested by @SarahBornais , who brings up a good point - we currently manage passwords through ad-hoc sharing or the private exec repository, which is pretty jank and unsafe.

My only concern with self-hosting our secrets is losing access to our instance of the secrets service would be a pretty big problem, whereas our current approach with the exec repository feels pretty permanent (if unsafe)

[chuck-sys]

Interesting. A suggestion about losing access to a self-hosted secrets service would be to have an encrypted backup stored somewhere, with a key that only a select few would know.

Of course, all stored secrets would probably be encrypted symmetrically (some AES) and encoded in Base64. The keys would be distributed to organizational admins, and provided as an environmental variable.

More advanced ideas include Shamir's secret sharing, where only when multiple sub-keys come together (but not all of them) that we can decrypt things (probably some last-ditch effort). But our secrets aren't that important, right?

[bobheadxi]

But our secrets aren't that important, right?

If we set this up, I would migrate all our credentials over and they would be pretty important - things like:

[chuck-sys]

Ah. That's quite a few there.

[bobheadxi]

A suggestion about losing access to a self-hosted secrets service would be to have an encrypted backup stored somewhere, with a key that only a select few would know.

I imagine Vault would have some built-in support for this

Of course, all stored secrets would probably be encrypted symmetrically (some AES) and encoded in Base64. The keys would be distributed to organizational admins, and provided as an environmental variable.

This is assuming we DIY the secret management system ourselves, instead of using a service like Vault right?

[chuck-sys]

This is assuming we DIY the secret management system ourselves, instead of using a service like Vault right?

Yes.

Btw: if we are going with a DIY secret management, the act of adding a secret via /rocket secret add Github "mygithubpassword111" exposes the password in the logs. Which are difficult (I would not want to say impossible) to breach. A possible solution would be to pre-encrypt the password and send it in via base64.

[bobheadxi]

the act of adding a secret via /rocket secret add Github "mygithubpassword111" exposes the password in the logs

I would call this pretty bad 🤔 Maybe we can exclude/do special preprocessing for the chain of commands in /rocket secret? This would tie in nicely with #519 (scoped loggers)

[chuck-sys]

Maybe we can exclude/do special preprocessing

I wonder if we can replace the actual password with *******....

[bobheadxi]

^ That would be the standard approach if we have a hook for special preprocessing of the logged command