Page MenuHomePhabricator

Create a new ldap group for sre users without root access
Closed, ResolvedPublic

Description

The ops group, which is ussally assigned to SREs enables a lot of privileges such as root access to all productions severs as such we have started to limit access to this group while new hires complete there onboarding and get more familure with the WMF infrastructure. However there are still a lot of services which new SRE's need to be able to access which may otherwise be restricted to only the ops group (i.e. wmf ldap group dose not have access) .e.g puppetboard. Or possibly additional access to various gerrit repos

To enable this additional layer of access control we should create a new ldap group. This should be a simple thing to do but suggestions for names for the new group most welcome :)

Event Timeline

jbond triaged this task as Medium priority.Aug 26 2021, 1:56 PM
jbond created this task.
jbond renamed this task from Creat a new ldap group for sre useres without root access to Creat a new ldap group for sre users without root access.Aug 26 2021, 2:23 PM

im nor sure how easy it would be to rename the ops group however it seems a genral convnsion for simlar things is to have:

  • $team-roots for root access
  • $team-admin for reduced set of ACL's

so perhpas

  • rename ops -> sre-roots
  • sre-admins for the new group

I like the rationale, at the same time I think that renaming ops might be a never ending work. Maybe we could adopt the new sre-admins without renaming ops for now. Just my 2 cents.

I like the rationale, at the same time I think that renaming ops might be a never ending work. Maybe we could adopt the new sre-admins without renaming ops for now. Just my 2 cents.

yes i agree, ill add this tomorrow

I like the rationale, at the same time I think that renaming ops might be a never ending work. Maybe we could adopt the new sre-admins without renaming ops for now. Just my 2 cents.

yes i agree, ill add this tomorrow

Sorry this slipped of my radar, i have now added the ldap group sre-admins and added Arnold to it.

Change 715731 had a related patch set uploaded (by Jbond; author: John Bond):

[operations/puppet@production] admin: create new sre-admins group to match the ldap group

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

@MoritzMuehlenhoff i created the new sre-admins ldap group manually as i couldn't see a puppet way. pinging incase i missed something.

Change 715731 merged by Jbond:

[operations/puppet@production] admin: create new sre-admins group to match the ldap group

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

Change 715733 had a related patch set uploaded (by Jbond; author: John Bond):

[operations/puppet@production] admin: add sre-admins to the always group

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

Mentioned in SAL (#wikimedia-operations) [2021-08-31T14:02:04Z] <jbond@cumin1001> START - Cookbook sre.hosts.downtime for 4:00:00 on puppetdb1002.eqiad.wmnet with reason: puppetdb maintance - T289779

Mentioned in SAL (#wikimedia-operations) [2021-08-31T14:02:08Z] <jbond@cumin1001> END (PASS) - Cookbook sre.hosts.downtime (exit_code=0) for 4:00:00 on puppetdb1002.eqiad.wmnet with reason: puppetdb maintance - T289779

Mentioned in SAL (#wikimedia-operations) [2021-08-31T14:02:21Z] <jbond@cumin1001> START - Cookbook sre.hosts.downtime for 4:00:00 on puppetdb2002.codfw.wmnet with reason: puppetdb maintance - T289779

Mentioned in SAL (#wikimedia-operations) [2021-08-31T14:02:25Z] <jbond@cumin1001> END (PASS) - Cookbook sre.hosts.downtime (exit_code=0) for 4:00:00 on puppetdb2002.codfw.wmnet with reason: puppetdb maintance - T289779

Sorry the stashdot spam should have gone to T263578

In an onboarding meeting with @Arnoldokoth just now, @Volans made the excellent point that sre-admins access should include root on the sretest* hosts, for experimentation, practice, and hands-on training.

We will also need to update https://wikitech.wikimedia.org/wiki/LDAP/Groups with the new sre-admins group (although lest delay that until we have worked out the initial teething issues)

Aklapper renamed this task from Creat a new ldap group for sre users without root access to Create a new ldap group for sre users without root access.Sep 1 2021, 7:53 AM

Change 715733 merged by Jbond:

[operations/puppet@production] admin: add sre-admins to the always group

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

In an onboarding meeting with @Arnoldokoth just now, @Volans made the excellent point that sre-admins access should include root on the sretest* hosts, for experimentation, practice, and hands-on training.

This has now been completed i have also added sre-admins to the default_groups so they should be able to login everywhere

We will also need to update https://wikitech.wikimedia.org/wiki/LDAP/Groups with the new sre-admins group (although lest delay that until we have worked out the initial teething issues)

done, closing this as i think everything is done but please reopen if i missed something

It seems sre-admins isn't in the list above the ToC, and https://wikitech.wikimedia.org/wiki/LDAP/Groups#sre-admins_group does not list what it grants access to

@MoritzMuehlenhoff i created the new sre-admins ldap group manually as i couldn't see a puppet way. pinging incase i missed something.

Ack, that's correct. The initial group creation happens manually (it happens very rarely anyway).

It seems sre-admins isn't in the list above the ToC, and https://wikitech.wikimedia.org/wiki/LDAP/Groups#sre-admins_group does not list what it grants access to

I have updaetd the list at the top of the wiki page, as to access currently the ldap group doesn't enable any access. however that will probably change.

@RLazarus do you have a list in mind of what this group should access. will probably need further discussion and further authorisation but as you were (i think) the onboarding buddy for the current member i figured you probably have an idea for a good starting point?

I don't have a specific list in mind. I think the best approach is to take the list for ldap/ops and pare it down -- which of those things can't we include? But otherwise let's include everything we can.

Example: We don't want sre-admins to grant root on all hosts. As a corollary, it also shouldn't grant +2 rights in operations/puppet, so that you can't grant yourself root. (Technically you still wouldn't be able to sudo puppet-merge it, but let's still leave out ops/puppet rights for defense-in-depth, and for simplicity.)

There might be other items we want to restrict, but I think we should err on the side of including things unless they're extremely high risk, the way global root is. Our stance should still be that members of sre-admins are people we trust, who need privileged access to do their jobs -- they're just still in training, so it's only the riskiest things that we want to cordon off at first.

(As an implementation detail, I think we can also leave out all the stuff that's granted by membership in ldap/wmf, since any member of sre-admins will always be in there.)

Change 722884 had a related patch set uploaded (by Jbond; author: John Bond):

[operations/puppet@production] O:idp: update access permissions for sre-admins

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

thanks i have gone through and it seems that the list of services is fairly small and includes puppetboard, librenms and orchestrator. i have created a CR to start getting approvals

Change 722884 merged by Jbond:

[operations/puppet@production] O:idp: update access permissions for sre-admins

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

Thanks all i have updated added the additional ldap permissions and updated the wiki page