Page MenuHomePhabricator

Password Vault for Security Team
Closed, ResolvedPublic

Description

SRE and Release-Engineering-Team both currently have password vaults for sharing passwords between team members, where individual accounts doesn't make sense due to complexity of setting up user rights etc.

People who would need access would be myself, @Bawolff and our new Director, John Bennett (who I don't think is on phabricator yet)

Event Timeline

Ops and Releng are using pwstore, which is just using a simple git repository underneath for storage.

The repo for Ops is stored on a private host and IIRC RelEng was investigating the use of a private Phab repo for storage (but better doublecheck with @thcipriani, the last I've seen of that is https://phabricator.wikimedia.org/T171342#3462054), that would probably also work for you?

We did use a private repo in Phabricator. It's worked great. We can set you up with a similar repo, otherwise pwstore is pretty self-service between the participants.

Something like that sounds fine, yeah.

Be nice to do something that isn't wheel re-inventing obviously, so if we can follow what releng do... That works for me :)

Some general docs (targeted at ops pwstore, but pretty similar) are at https://office.wikimedia.org/wiki/Pwstore

Our process in Releng is identical, save the "where to clone from" bit.

Our repo (https://phabricator.wikimedia.org/source/releng-secrets/repository/master/ ) haha you can't see it! ;) but yeah, it's straight-forward to make private repos in Phab if you want that, let us know!

Cool. I'll check in with Brian/John that they're ok with doing it like this before we go ahead and actually create anything

Reedy triaged this task as Medium priority.Jan 18 2018, 6:34 PM

Do we actually have shared secrets?

Im fine with the private repo approach (the repo is secret and then pgp on top of that, right?)

Do we actually have shared secrets?

Not really at the moment, but I'd imagine there's stuff other teams have that we should probably have access to for varying reasons. Including, but not limited to the packagist wikimedia/mediawiki accounts

Im fine with the private repo approach (the repo is secret and then pgp on top of that, right?)

Right.

Couple questions:
*Is each 'group' required to have their own repo? How is that access and credential sharing determined?
*If that's not the case, how will we prevent credential disclosure to folks who have access to the repo but dont have a need to know all the creds?
*Do people know to update creds when someone no longer requires access to them (leaves the foundation, changes groups, etc)?

Couple questions:
*Is each 'group' required to have their own repo? How is that access and credential sharing determined?

Nope, it's a function of how many different "groups" of people need to access things. In practice, we've just been using one group for all of RelEng. In theory, we could have a big password store for all WMF, with each group getting some passwords and not others. "Who can access what password" is determined in the yaml file themselves. Here's an example:

qa@lists.wikimedia.org entry:
access: "@admins"
password: <snip snip>
site: https://lists.wikimedia.org/mailman/admin/qa

*If that's not the case, how will we prevent credential disclosure to folks who have access to the repo but dont have a need to know all the creds?

See above, this should be fine. All they would see is a PGP-encrypted blob they couldn't view. Same thing if I sent you the raw files from the RelEng repo.

*Do people know to update creds when someone no longer requires access to them (leaves the foundation, changes groups, etc)?

pws does let you know when you should probably reencrypt something when you're done editing it:

Notice: list of keys changed -- re-encryption recommended.  Run pws rc foo.yaml

Здравствуйте! Я новенький, имею желание помогать и развивать Wikimedia. Что для этого нужно сделать?

sbassett assigned this task to Reedy.
sbassett subscribed.

I think this can be resolved for now, since I believe @Reedy set this up for the Security-Team.