Page MenuHomePhabricator

Password Vault for Security Team
Open, NormalPublic

Description

Operations 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

Reedy created this task.Jan 18 2018, 6:02 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 18 2018, 6:02 PM

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?

demon added a subscriber: demon.EditedJan 18 2018, 6:11 PM

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.

Reedy added a comment.Jan 18 2018, 6:13 PM

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

demon added a comment.Jan 18 2018, 6:23 PM

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

greg added a subscriber: greg.Jan 18 2018, 6:24 PM

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!

Reedy added a comment.Jan 18 2018, 6:28 PM

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 Normal 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?)

Reedy added a comment.Jan 18 2018, 6:51 PM

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

greg added a comment.Jan 18 2018, 7:04 PM

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)?

demon added a comment.Feb 23 2018, 9:10 PM

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