ubclaunchpad / rocket2

🚀 The official UBC Launch Pad Slack bot and team management platform
https://rocket2.readthedocs.io
Other
18 stars 6 forks source link

proposal: secrets management #557

Open bobheadxi opened 4 years ago

bobheadxi commented 4 years ago

Summary

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

Requirements

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Ah. That's quite a few there.

bobheadxi commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Maybe we can exclude/do special preprocessing

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

bobheadxi commented 4 years ago

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