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 (SRE/MWE: +ARVeiorstv)
 * Command: /msg ChanServ FLAGS #miraheze-sre [nick] sre
 * #miraheze-sre-security (SRE/MWE: +ARVeiorstv)
 * Command: /msg ChanServ FLAGS #miraheze-sre-security [nick] sre
 * /mode +I should also be given
 * Command: /mode #miraheze-sre-security +I $a:[nick]
 * 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 (SRE/MWE: +AVeotv)
 * Command: /msg ChanServ FLAGS #miraheze-ops [nick] op
 * #miraheze-feed (SRE: +ARSVefiorstv, MWE: +ARVefiorstv)
 * #miraheze-feed-login (SRE/MWE: +AORefiorstv)
 * Channel Operators should be added to the relevant config in MirahezeBot for 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 given 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 is also a Phabricator administrator, that must also be revoked on off-boarding.

Wikis

 * For MediaWiki system administrators, 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 the purpose of 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

 * If a new system administrator wishes, they may request access to the @miraheze Twitter account.
 * Access to the Twitter account 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 RamNode

 * 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

 * Site Reliability Engineers and Puppet Users should be talked through how private git works and how to access and commit things to it. This is granted through root on puppet3 and no specific access is necessary besides puppet3 root.