Page MenuHomePhabricator

Requesting access to ops group for nskaggs
Closed, ResolvedPublicRequest

Description

Requestor provided information and prerequisites

This section is to be completed by the individual requesting access.

  • Wikitech username: nskaggs
  • Email address: nskaggs@wikimedia.org
  • SSH public key (must be a separate key from Wikimedia cloud SSH access): ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJrQktvFtYDgqDLSijTL+6ot1XyAAR31hlFMTZGKTc5o
  • Requested group membership: global-root
  • Reason for access: I've have tried to stick with WMCS level root access to better understand limitations and advocate for WMCS volunteer access. Over time, I found frequent blockers that prevented my ability to perform needed tasks. Typically this has resulted in asking someone else for help, or getting carve outs to run specific commands (for example, cumin access to run specific cookbooks). This was helpful for me to understand and the limitations I encountered helped raise the access levels of those in similar circumstances, including volunteers. However, trying to help with an Unbreak now level task today, resulted in me not having access to cloudb and dbproxy nodes needed to help. T337446: Rebuild sanitarium hosts Given the potential for critical tasks to recur, it would be helpful to simply have global root.

See T258438 for previous request.

  • Name of approving party (manager for WMF/WMDE staff): Kate Chapman
  • Ensure you have signed the L3 Wikimedia Server Access Responsibilities document: Yes
  • Please coordinate obtaining a comment of approval on this task from the approving party.

SRE Clinic Duty Confirmation Checklist for Access Requests

This checklist should be used on all access requests to ensure that all steps are covered, including expansion to existing access. Please double check the step has been completed before checking it off.

This section is to be confirmed and completed by a member of the SRE team.

  • - User has signed the L3 Acknowledgement of Wikimedia Server Access Responsibilities Document.
  • - User has a valid NDA on file with WMF legal. (All WMF Staff/Contractor hiring are covered by NDA. Other users can be validated via the NDA tracking sheet)
  • - User has provided the following: wikitech username, email address, and full reasoning for access (including what commands and/or tasks they expect to perform)
  • - User has provided a public SSH key. This ssh key pair should only be used for WMF cluster access, and not shared with any other service (this includes not sharing with WMCS access, no shared keys.)
  • - The provided SSH key has been confirmed out of band and is verified not being used in WMCS.
  • - access request (or expansion) has sign off of WMF sponsor/manager (sponsor for volunteers, manager for wmf staff)
  • - access request (or expansion) has sign off of group approver indicated by the approval field in data.yaml

For additional details regarding access request requirements, please see https://wikitech.wikimedia.org/wiki/Requesting_shell_access

Event Timeline

Technically this is a request for membership in group "ops". So that is treated like any other "add user to existing group" process per https://wikitech.wikimedia.org/wiki/SRE/Production_access . There is nothing special like "has to be in SRE meeting" anymore. Is that right @Muehlenhoff ?

So looks like we need approval from one (or more?) of:

approval:
  - Chris Albon
  - Guillaume Lederrey
  - Joanna Borun
  - Kavitha Appakayala
  - Kwaku Addo Ofori
  - Leo Mata
  - Lukasz Sobanski
  - Mark Bergsma
  - Nicholas Skaggs
  - Olja Dimitrjevic

note: requestor is group approver for the root group :)

Change 923665 had a related patch set uploaded (by Nskaggs; author: Nskaggs):

[operations/puppet@production] Add nskaggs to global root

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

nskaggs renamed this task from Requesting access to global root for nskaggs to Requesting access to ops group for nskaggs.May 26 2023, 4:36 PM

Change 923667 had a related patch set uploaded (by Jbond; author: jbond):

[operations/puppet@production] admin: add nskaggs to ops

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

jbond triaged this task as Medium priority.May 26 2023, 4:44 PM

Change 923667 abandoned by Jbond:

[operations/puppet@production] admin: add nskaggs to ops

Reason:

for
https://gerrit.wikimedia.org/r/c/operations/puppet/+/923665

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

Technically this is a request for membership in group "ops". So that is treated like any other "add user to existing group" process per https://wikitech.wikimedia.org/wiki/SRE/Production_access . There is nothing special like "has to be in SRE meeting" anymore. Is that right @Muehlenhoff ?

So looks like we need approval from one (or more?) of:

approval:
  - Chris Albon
  - Guillaume Lederrey
  - Joanna Borun
  - Kavitha Appakayala
  - Kwaku Addo Ofori
  - Leo Mata
  - Lukasz Sobanski
  - Mark Bergsma
  - Nicholas Skaggs
  - Olja Dimitrjevic

note: requestor is group approver for the root group :)

Approved.

Change 923665 merged by Jbond:

[operations/puppet@production] Add nskaggs to global root

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

I'm wondering if this was the right long term approach. In general we're trying to reduce the need for global root, not expand it.
I see that we already have a wmcs-roots group in modules/admin/data/data.yaml that has full sudo permissions on the hosts where it's applied adding it to the hiera profile::admin::groups setting.
I wonder if that would be a more suitable solution for the cloudb hosts and similar other clusters related to WMCS.

Membership of ops group in LDAP and YAML are not identical: ['fabfur', 'nskaggs']

^ this would still need to be fixed

I'm wondering if this was the right long term approach. In general we're trying to reduce the need for global root, not expand it.
I see that we already have a wmcs-roots group in modules/admin/data/data.yaml that has full sudo permissions on the hosts where it's applied adding it to the hiera profile::admin::groups setting.
I wonder if that would be a more suitable solution for the cloudb hosts and similar other clusters related to WMCS.

Have a look at T337848: WMCS-roots wiki replica access and associated patches. Comments / reviews welcome. There is still a need to correct the specific reason for this request. Enabling wmcs-roots and other groups to ensure root on machines they are responsible for will reduce the need for global root permissions. For example, T261145: Enable access for wmcs-admins to run wmcs-prefixed cookbooks on cumin hosts which you helped enable (thank you!), helps alleviate the need for root on machines when automation exists to run tasks on a production host. The cloudcumin hosts, combined with other changes, such as networking changes allowing more WMCS hosts to move inside WMCS VLAN (see https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/Iteration_on_network_isolation and T297596: have cloud hardware servers in the cloud realm using a dedicated LB layer ), will also help. In short, I agree with your stated intent to reduce the need for global root over the long term. Keep the ideas coming, and thanks for helping!

This ticket seems technically resolved. What, if any, would be the next step here? Is it still in discussion?

SLyngshede-WMF subscribed.

I think we can close this.