restricted is historic. there used to be just 3 levels. restricted was the lower level, then "mortals" with deployer rights and finally root.

There is not much reason to keep it as it. We should go through the list of people in "restricted" and ask:

• who is still using their access in the first place. if not, remove
• the ones who actually use it, what do they do with it
• then either 'upgrade' them to deployers or find other matching groups or make new groups that are for specific tasks or services

and then delete this

and re; bastion access it should definitely either give ALL bastions or NONE (and then we use bastiononly in addition). one of the 2 option, but not some random mix.

When I wrote this, this group also had access to erbium.eqiad.wmnet where I believe there were some webrequest logs. That host is now gone and the group's permissions now appear to be a proper subset of the deployment group permissions.

Thanks Krenair! erbium-related change: https://gerrit.wikimedia.org/r/#/c/297732/

updated the table for both myself and Joe (who at the moment is there generally to shadow and back me up). I obviously don't really care what specific rights group we have but I'm not sure any other groups currently exist for our use case other then restricted (unless we were upgraded to deployer obviously which I leave to others, I generally work under 'least access' type rules but there are obviously different things to balance). The biggest things we get out of restricted and need to keep:

• full db access (including occasionally the need for write access)
• Maintenance script access

So how are we doing this? I guess let's first check if we have any inactive users in this list and remove them. Anyone in this group who says they don't need access anymore? Anyone who always wanted to become a full deployer anyways?

@Krenair I don't know what kind of access/privileges I've been getting by being in "restricted". :( I double-checked with Analytics to make sure by not being in that group I don't loose access to Bastion and the production servers. It seems being part of "restricted" is separate from the Analytics services I need access to. Based on all this, I'll fill out the table here, but I'd appreciate if someone can point me to where I can learn about what this access meant for me. :)

I've prepared a change to remove users from deployment group from the restricted group, that will help to get a more accurate list to revisit.

$ python
>>> import yaml

>>> d = yaml.safe_load(open('modules/admin/data/data.yaml'))
>>> set(d['groups']['restricted']['members']) & set(d['groups']['deployment']['members'])
set(['khorn', 'ssastry', 'addshore', 'hoo', 'nuria', 'legoktm'])

>>> d = yaml.safe_load(open('modules/admin/data/data.yaml'))
>>> set(d['groups']['restricted']['members']) & set(d['groups']['deployment']['members'])
set([])

Change 364469 had a related patch set uploaded (by Dereckson; owner: Dereckson):
[operations/puppet@production] Remove deployers from restricted group

https://gerrit.wikimedia.org/r/364469

There is no dupe for ops/restricted by the way.

>>> set(d['groups']['restricted']['members']) & set(d['groups']['ops']['members'])
set([])

Change 364469 merged by Dzahn:
[operations/puppet@production] admin: Remove deployers from restricted group

https://gerrit.wikimedia.org/r/364469

the following users have been removed from the group: hoo khorn ssastry nuria legoktm addshore

all of them were (and are) already in "deployers".