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.

In T289779#7312004, @Volans wrote:

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

In T289779#7312744, @jbond wrote:

In T289779#7312004, @Volans wrote:

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)

Change 715733 merged by Jbond:

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

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

In T289779#7322102, @RLazarus wrote:

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

In T289779#7321535, @jbond wrote:

@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).

In T289779#7325056, @Aklapper wrote:

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