Tech:On-Off Boarding

This page groups together all documentation over on and off boarding volunteers with a level of escalated permissions (shell is the main one here right now). The page is written in the tense of on-boarding and any changes where necessary in the case of offboarding will be written below it.

For each onboarding or offboarding process, a Phabricator task must be created with a checklist to track the status of all actions. This is to ensure people have the proper rights during onboarding and minimal rights after offboarding.

Shell
This section is generic to all shell requests.

Email

 * Add a mail account for the user.

IRC

 * Elevation of rights in the following channels may be given:
 * #miraheze (SRE: +ARVefiorstv, MWE: +AVeotv)
 * #miraheze-offtopic (SRE: +ARVefiorstv, MWE: +AVeotv)
 * #miraheze-sre (+ARVeiorstv)
 * Command:
 * #miraheze-sre-security (+ARVeiorstv)
 * Command:
 * /mode +I should also be given
 * Command:
 * Access must be revoked on off-boarding, no exceptions (unless the user is a Board member, or has approval by an Engineering Manager).
 * #miraheze-ops (+AVeotv)
 * Command:
 * #miraheze-feed (+ARSVefiorstv)
 * #miraheze-feed-login (+AORefiorstv)
 * Channel Operators should be added to the relevant config in FOSSBots for MirahezeBot channel management.
 * On off-boarding, +V should be taken away. Ops access can stay in non-confidential channels if the user is trustworthy. If ops access is removed, revoke MirahezeBot channel management access.

GitHub

 * The user should be added to the relevant team in the GitHub account (usually mw-admins) which then provides sufficient access to push commits to the repositories they need to fulfil their role.
 * Access must be revoked on off-boarding, no exceptions.

LDAP

 * An LDAP account should be made for a new MediaWiki Engineer or Site Reliability Engineer.
 * On off-boarding, the LDAP account would not necessarily need to be deleted as long as the user doesn't have access to anything private or to execute anything. However, for extra security reasons, the password of the account should be changed to a random hash so that the account can no longer be accessed, but can still exist in the database.
 * Add the user to the relevant LDAP groups (which also determine the emails they receive).

Grafana

 * New MediaWiki Engineers or Site Reliability Engineers being on-boarded should be given adminship to Grafana.
 * Access must be revoked on off-boarding, no exceptions.

Graylog

 * New MediaWiki Engineers or Site Reliability Engineers must receive access to Graylog. MediaWiki Engineers: grant Reader role only, you should share access to the MediaWiki related streams in Graylog. Site Reliability Engineer: grant Admin role.
 * Access must be revoked on off-boarding, no exceptions.

Matomo

 * The user may be provided access to Matomo, our analytics platform. There are separate groups for MediaWiki Engineers and Site Reliability Engineers.
 * On off-boarding, this should be revoked by default, although there may be legitimate reasons to keep access.

Monitoring

 * If the user wants monitoring alerts via email, add them to icinga and then add them to a monitoring group.
 * On off-boarding, remove both contact and the addition to group definitions for the user.

Status Page

 * System administrators may also be added to http://status.miraheze.wiki/, which is done via hund.io.
 * Access should be revoked on off-boarding.

Phabricator

 * Add the user to the acl*security group, so they can function effectively in the worst-case scenario of a security issue.
 * On off-boarding, this group must be revoked. If the user thinks they have an important reason to keep access, please discuss with the SRE Management team.
 * If the user wishes, and is eligible under the access policy, grant Phabricator administrator.
 * Must be revoked on off-boarding.

Wikis

 * For MediaWiki Engineers, the global system administrator group may be useful - it is, however, not a strict requirement.
 * On off-boarding, any access to global groups or technical wikis must be revoked if it was for being a volunteer with shell or privileged access.
 * Access to staffwiki can be granted to users holding shell access.
 * On off-boarding, this group must be revoked (both on-wiki and in LocalSettings.php), unless the user is also a Board member. In said case, please do not remove those groups.

Twitter
As of writing, TweetDeck seems not to be available to volunteers in all regions due to new Twitter policies. The account for the Twitter password must only be shared with SRE members who demonstrate a clear need for such access.
 * If a new system administrator wishes, they may request access to the @miraheze and @MirahezeStatus Twitter accounts.
 * Access to the Twitter accounts should be revoked on off-boarding, unless the user intends to keep managing social media and is trustworthy enough. Use your judgement.

Facebook

 * If a new system administrator wishes, they may request access to the @miraheze Facebook page.
 * Access to the Facebook page should be revoked on off-boarding, unless the user intends to keep managing social media and is trustworthy enough. Use your judgement.

Site Reliability Engineering
The above applies, this section covers things which are specific to operations only.

OVH and 1&1

 * Basic access to the two accounts for ticketing purposes and the 'operations back door' should be granted. This should be so any operations member can fulfil their duties on their own.
 * Access must be revoked on off-boarding, no exceptions.

Private Git

 * Infrastructure Engineers should be talked through how private git works and how to access and commit things to it. This is granted through root on puppet141 and no specific access is necessary besides puppet141 root.

Google Services
This service requires 2FA and accounts are automatically suspended if it is not enabled within 24 hours of creation. If a member of SRE needs access to Google Search Console or Google Cloud (for ReCaptcha), please ask MediaWiki SRE to create them an account in Cloud Identity. A valid miraheze.org email must exist for access on file. Please make sure to add a backup email and list the users' manager. On off boarding, this access must be suspended. You should manually check search console for delegated access. This may need Owner rights. If a linked device is stolen, devices may be banned from the devices section of the admin portal rather than suspending an account.