No defined process other than create a task and wait for someone to action. There are two types of admins: sysop and contentadmin. With the creation and rollout of interface admins probably the segregation doesn't make much of the sense that it had in the past, though; although probably still makes sense. Usually @bd808 or @scfc handled user rights requests in the past for me, so I'm taking the liberty to mention them in here. Regards.

I wonder if the only legitimate use case for modifying that page is accompanied by the ability to change that SSH key, and so potentially is sanest as a right limited to toolforge admins/roots.

In this case the page needed to be updated not because the keys on any system changed, but because the hostname was changed to point to a different system (tools-sgebastion-[06→07], due to the WMCS incident).

In T216126#4954435, @Lucas_Werkmeister_WMDE wrote:

In this case the page needed to be updated not because the keys on any system changed, but because the hostname was changed to point to a different system (tools-sgebastion-[06→07], due to the WMCS incident).

yeah totally, and I'm not trying to be emphatic about this -- more curious. That action (replacing the host) would also be an activity limited to toolforge admins. I worry that any other group of folks are not adequately able to ensure it's the right key before updating the page.

In T216126#4954449, @chasemp wrote:

activity limited to toolforge admins

IFF all toolforge admins do belong to a particular user group (cloudadmin?) then we can profit from $wgRestrictionLevels and create a new restriction (clouadmin protected) so that or other pages could be protected and editted only by cloud administrators.

Tools is a small fraction of the stuff with fingerprints recorded on wikitech: https://wikitech.wikimedia.org/wiki/Help:SSH_Fingerprints

WP:BEANS, but sysop on wikitech is a very sensitive user right. For the particular content in question, page protection restrictions are reasonable to prevent edits from bad actors who have somehow figured out how to ssh connections to compromised servers.

contentadmin can edit normal protected pages, and seems reasonable for anyone with deploy access. The page there even gives a handy form for requesting it ;-)

@Lucas_Werkmeister_WMDE I have changed the title here to reflect a request for contentadmin. Granting full sysop on Wikitech is unlikely without also granting Cloud-wide root. Contentadmin is a much easier right to approve, assuming that you have a desire to help maintain sensitive content on wikitech in the long term. Please do respond here an let us know if you are actively seeking this right or were just a bit annoyed to find that there was content that you could not change on wikitech.

Well, it was more out of surprise that I was told to edit the page and then couldn’t do it, but since I do edit content on Wikitech from time to time, it would be useful to have this right, sure. (Though I don’t think I’ve run into protected pages before – most of my contributions outside of Wikidata stuff are just random things I find while going through the documentation.)