It is not really clear to me on next steps for updating the phabricator form, as it seems blocked by some decisions:

• Requested group membership (proposed: drop down menu, with option to enter free form)
  • Researchers: Access statistics number crunching hosts (like statistics-users) and also provides access to research mysql credentials on stat1006 (currently the only such host)
  • Analytics-users: Gives generic client access to the Analytics (Hadoop) cluster. This will grant shell access on Hadoop client nodes and on Hadoop NameNodes.
  • Analytics-privatedata-users: Gives access to the Analytics (Hadoop) cluster as well as private data within. This will grant shell access on Hadoop client nodes and on Hadoop NameNodes. Some files in HDFS have sensitive data in them.
  • Statistics-users: Access statistics number crunching hosts. NO PRIVS.
  • Statistics-privatedata-users: Access to stat boxes that host private data, including sampled webrequest logs. This group should not be used just to grant someone Hadoop access. If someone wants access to access webrequest logs in the Hadoop cluster you should put them in the analytics-privatedata-users group. If they want Hadoop access without rights to private data, add them instead to the analytics-users group. [] [] statistics-* groups DO NOT EQUAL Hadoop/Hive cluster access.
  • deployment: replaces 'mortals' for mw software deployment
  • Other: (free form text field)
• Reason for access:
• Name of approving party (hiring manager, for WMF staff):

This needs to be freeform, because I'm not sure how to do a drop down in a form like this, because its making custom form stuff that likely isn't standard. I could be wrong though.

I took a first crack at updating the form: https://phabricator.wikimedia.org/maniphest/task/edit/form/8/

We likely want to decide what part of the full directions should be included in the preamble section, since most folks won't bother to read links.

Current Preamble: Use this form to create an Access Request task. See Requesting_shell_access for instructions.

Updated Preable (I was bold):

Eligibility

Production access is regulated by [[mw:Wikimedia Site Reliability Engineering|SRE team]]; they grant it only when it is strictly needed and can deny any request that that creates an unacceptable security risk.

A request that is likely to be granted needs to contain three main things:

1. A '''clear, ongoing need''' for the access. Requests based on a one-time need will not be granted. if you have a one-time need for data, request the data instead.
2. A '''non-disclosure agreement''' with the Wikimedia Foundation. If you work for the Foundation, this was probably included in your employment agreement. Otherwise, you'll have to follow [[Volunteer NDA#Privileged LDAP or shell access|the volunteer NDA process]].
3. '''Support from a relevant Wikimedia Foundation employee'''. If you work for the Foundation, this should be your supervisor; otherwise, this should be the employee you will be collaborating with.

Request process

[[File:Gamagory shell museum2 2004.jpg|thumb|right|Shells!]]If you've satisified the eligibility requirements above, you can make the access request by following these instructions.

Accounts

To follow these instructions, you'll need the following accounts:

• A [[phab:|Phabricator]] account. If you don't have one, see the instructions [[mw:Phabricator/Help#Creating your account|for creating an account on mediawiki.org]].
• A [[Help:Create a Wikimedia developer account|Wikimedia developer account]]. If you don't have one, follow the link.

Signing the agreement

Next, read and sign the [[phab:L3|Acknowledgement of Wikimedia Server Access Responsibilities]]. Make sure you actually read it; this is a legal agreement and by signing it, you are committing to follow the security practices it describes.

Generating your SSH key

Since production access uses the [[:en:Secure_Shell|Secure Shell protocol]] (SSH), you'll have to generate a '''new''' SSH keypair. Do '''not''' reuse an existing key; this presents an unacceptable security risk.

GitHub has a [https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/#platform-mac good help page] (note that you can switch between Mac, Windows, and Linux documentation right under the title).

We recommend that you use an ED25519 key (or, alternatively, a 4096-bit RSA key). Do ''not'' use DSA keys as they are insecure and rejected by our SSH servers.

To generate an ED25519 key, run the following command in your terminal:
<syntaxhighlight lang="bash">
ssh-keygen -t ed25519
</syntaxhighlight>

To generate an RSA key, run the following command in your terminal:
<syntaxhighlight lang="bash">
ssh-keygen -t rsa -b 4096 -o
</syntaxhighlight>
''Some systems don't support the newer <code>-o</code> option which saves private keys in a slightly more secure format (OpenSSH rather than PEM), but those should be fairly rare, it was introduced in 6.5''

The minimum bit length for this key is <code>-b 2048</code>, which is currently the default length for OpenSSH. More bits won't hurt.

Remember: the key you use for production access must be different from the key you use for [[Portal:Cloud VPS|Cloud VPS]], so do '''not''' paste it into the Openstack field under Special:Preferences on this wiki).

I've updated the task description to list out the sections of the form and what is listed in each section.

The only section I am unclear on how we want to proceed is:

• Requested group membership (proposed: drop down menu, with option to enter free form)

The issues I see with providing a drop down are as follows:

• I have no idea how to create a custom field in phabricator, and uncertain what the implications would be. My understanding is we do NOT want our phabricator installation to diverge from standard too much, so if its a lot of custom hacking that is bad.
• We would have to manually update that array of groups, or have someone program some kind of phabrictor form to our puppet repo data.yaml merged file for our admin module. This seems like an unreasonable amount of linkage in short term.
• If we simply list a free form field, no changes to form implementation are needed. I advise we start with free form (and I've done that on the form field for now) and investigate the above for feasibility.

I'd like to edit the form but don't currently have permission. Primarily I'd like to add the clinic duty checklist and clarify a few prerequisites for the requestor to complete. These are things that we currently do manually via back-and-forth comments. Adding them to the template should save time on every request. I'd like to update the template like so:

== Requestor provided information and prerequisites ==

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

* Wikitech username:
* Preferred shell username:
* Email address:
* Ssh public key (must be dedicated key for wmf production):
* Requested group membership:
* Reason for access:
* Name of approving party (hiring manager for WMF staff):
* Requestor -- Please Acknowledge that you have read and signed the L3 Wikimedia Server Access Responsibilities document: 
* Requestor -- 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.  (This can be checked by Operations via the NDA tracking sheet & is included in all WMF Staff/Contractor hiring.)
[] - User has provided the following: wikitech username, preferred shell 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 share with any other service (this includes not sharing with WMCS access, no shared keys.)
[] - access request (or expansion) has sign off of WMF sponsor/manager (sponser for volunteers, manager for wmf staff)
[] - non-sudo requests: 3 business day wait must pass with no objections being noted on the task
[] - Patchset for access request

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