tl;dr: please respond with your use cases and concerns about secret keys, passwords, etc on cloud-vps
Right now we have two not-very-good ways to distribute a secret key within a cloud project:
1) copy the secret onto each VM by hand as you create it
2) create a puppetmaster in your project and and have it distribute the secrets
Option #2 is pretty good for big, long-lived projects but involves a lot of overhead. Option #1 is fine for projects with only one or two VMs but scales terribly.
The WMCS team has been discussing the question of secrets distribution for years, and we have a few different possible solutions in mind but no favorite. Rather than rattle off those options here, we're trying to rewind a bit and gather possible use-cases and user wishes in this area.
So: if this is a feature you've been missing, please respond with an answer to this question:
"How would I make use of secrets on cloud-vps instances?"
If possible, please include thoughts about these points:
- Is it good enough to provide project-wide distribution, or do we need finer-grained control, limiting secrets to particular users or instances?
- Is a web UI for managing secrets a requirement, or are command line tools adequate? What if there were /only/ a web-ui and no command line?
- Would supporting secret management solve immediate issues on its own, or is it only useful as a part of larger instrumentation tooling (e.g. puppet, heat, or terraform integration)
Thank you! I welcome your thoughts on-list, but you're also welcome to list thoughts or use-cases on the phabricator tracking task https://phabricator.wikimedia.org/T283032
Hi,
On 5/17/21 12:39 PM, Andrew Bogott wrote:
"How would I make use of secrets on cloud-vps instances?"
I really only have one project right now that has secrets (LibUp). The mailman project has some secrets but it's a clone of our production setup so it seems logical (and maybe better?) that it uses secrets via puppet to mirror what's in prod, though setting them as a cherry-pick of labs/private on the puppetmaster is kind of a pain.
It's not super clear to me whether this proposed feature would mean you need to shell out to get secret values, hit a HTTP API, or if it's just a file on disk. Also can a secret be anything like a SSH private key? Or is it intended to be a password/token/string-like thing?
- Is it good enough to provide project-wide distribution, or do we need
finer-grained control, limiting secrets to particular users or instances?
I would prefer if I could pick the instances that get access to the secret, either by regex, prefix or some manual list.
If that's not possible, I think I'd want to be able to set the Unix group that could read/obtain the secrets so even though it's accessible on the instance, there's still some level of access control / privileged separation.
Basically I'd like to have some way to run a process that cannot access the secret.
- Is a web UI for managing secrets a requirement, or are command line
tools adequate? What if there were /only/ a web-ui and no command line?
I find a web UI usually superior to CLI tools, but I'd hope it would be integrated with Horizon and that I don't need to learn/remember a new web thing.
I don't think I'd care if there was no CLI interface.
- Would supporting secret management solve immediate issues on its own,
or is it only useful as a part of larger instrumentation tooling (e.g. puppet, heat, or terraform integration)
Having just secret management would be nice but it would probably be low priority on my Cloud VPS wishlist.
HTH, -- Legoktm