Page MenuHomePhabricator

Create auto-populated LDAP group of those who have production shell access
Open, MediumPublic

Description

It would be nice to be able to easily allow anyone who has shell access in production to send SRE pages using Klaxon, or more generally, to recognize this level of access from CAS SSO and from other LDAP clients.

We should add a new LDAP group which gets auto-synched daily from the admin module's data.yaml, the authoritative source of who has prod shell access.

A good name for this group is probably something like cn=prodshellaccess or perhaps cn=prodaccess. (We originally discussed cn=shellaccess, but this might be too easy to confuse with having shell access in either of prod or wmcloud.)

Event Timeline

This would practically be a subset of cn=wmf + cn=wmde + cn=nda, which I thought already had access to klaxon, per profile::klaxon. Am I missing some detail?

This would practically be a subset of cn=wmf + cn=wmde + cn=nda, which I thought already had access to klaxon, per profile::klaxon. Am I missing some detail?

I think the idea is to narrow down permissions to only those who actually have shell access and not the broad set of wmf/nda/wmde who only access some of our web services?

This would practically be a subset of cn=wmf + cn=wmde + cn=nda, which I thought already had access to klaxon, per profile::klaxon. Am I missing some detail?

I think the idea is to narrow down permissions to only those who actually have shell access and not the broad set of wmf/nda/wmde who only access some of our web services?

I think the idea is to try and lower the bar for users that can use klaxon. There are some users in admin.yaml that do not exist in wmf, nda or wmde. The proposal is to create a new group which covers this class of user.

I have created a quick script to list the users that fall into this catagory. The following list esencially includes user with ensure => present in admin.yaml who are not in any of the ldap groups nda, wmf, wmde. The output indicates which ldap groups the users are in and which posix groups they are in as per admin.yaml

ran on mwmaint1002

$ sudo ./admin.py -a ./data.yaml
The following users are not in any of the privalaged ldap groups
west1:  ldap_groups(project-tools,project-bastion)      posix groups(analytics-privatedata-users)
leizi:  ldap_groups()   posix groups(analytics-privatedata-users)
pearley:        ldap_groups()   posix groups(restricted,analytics-privatedata-users)
springle:       ldap_groups(project-puppet,project-analytics,project-tools,project-bastion)     posix groups(snapshot-users)
mbinder:        ldap_groups(project-bastion)    posix groups(phabricator-bulk-manager)
agaduran:       ldap_groups()   posix groups(analytics-privatedata-users)
ktsouroupidou:  ldap_groups()   posix groups(restricted,analytics-privatedata-users)
reprepro:       ldap_groups()   posix groups()
ezachte:        ldap_groups(project-bastion)    posix groups(restricted,analytics-privatedata-users)
jdcc:   ldap_groups()   posix groups(analytics-privatedata-users)
karen:  ldap_groups()   posix groups(restricted,analytics-privatedata-users)
cohi:   ldap_groups()   posix groups(analytics-privatedata-users)
CDanis triaged this task as Medium priority.Jan 15 2021, 4:58 PM

John has it right -- I wanted to lower the bar, and ensure all deployers / folks with any sort of shell access have Klaxon access. I wasn't sure that set was covered by wmf/wmde/nda; thanks to John for proving that is indeed the case :)

I would still like anyone in wmf/wmde/nda to be able to Klaxon, even if they do not have shell access.

Sidenote: if this is straightforward to do, it would be nice if we could create an LDAP group of users in the admin deployment group, so we can replace the manually maintained Gerrit wmf-deployment group with the auto-populated LDAP one.