Cleaning up state, handing off work, and removing access

This page is meant to track all the work that should be done when someone from Buildduty transitions off the team

Person Leaving Actions

LDAP, SSH, and VPN

• This is handled automatically by IT. Nothing to do.

Bugzilla & Github

• For bugs attached to you: resolve, un-assign yourself, or summarize current state and escalate where appropriate

IRC & Slack

• Because of the potential sensitive information occasionally shared in certain rooms, please drop fromf from all private (pw locked) channels.

Loaners & Host personal state

• If you have any machines on loan or artifacts living on remote machines, please clean those up where appropriate

Email & Calendar

• Both are controlled by LDAP and IT. Make sure you reach out to the target audience you want to connect with before access is revoked. This is a good time to pass on your permanent email and way to reach you, should you want to. It's also good to clear your calendar where it makes sense.

Manager Actions

LDAP, SSH, and VPN

If the person is leaving Mozilla

• SSH & VPN are managed by LDAP and login.mozilla.com. IT should handle this automatically when they revoke LDAP. This largely means you don't need to manually revoke machine and network access. Some caveats and code cleaning in sections later in this wiki

If the person is staying at Mozilla

• They will continue to have LDAP and therefore it would be good to sanity check that the releng/buildduty/balrog LDAP groups have been purged from their record.

Jumphost MFA

• file a ticket under "Infrastructure & Operations : RelOps" and request to revoke MFA jumphost access. Attach a patch that removes the person from the jumphost list.

Puppet and Signing Shortlist

• Some access privileges are defined within the puppet repo. Particularly who has authorized access to our signing servers. Go through this list and make sure it's up to date.

Taskcluster & Scopes

While Taskcluster accounts should largely be controlled by LDAP, scopes should be added or removed where appropriate. Particularly when people stay at Mozilla but leave Releng/Buildduty

Bugzilla & Github

• Find owners for dropped, unresolved bugs
• Find component owners where openings are made
• Remove person from github team and org where appropriate

IRC & Slack

• Rotate password protected channels

Email

• While this is automatically handled it is a good idea, for cleanliness sake, to sanity check list of recipients in private groups. e.g. buildduty@mozilla.com, release@mozilla.com

AWS

• Identity and Access Management (IAM) should be removed where appropriate

Secrets

This is the big one. In our private repo:

1. determine which encrypted files the person has access to 2. under COOKBOOK.txt, follow the steps under "4. How do I remove a user from a file" and remove access for the person leaving to every file they have access to. 3. remove the person from the users/*-fingerprints files. 4. To err on side of caution, it is best to rotate the passwords and keys the person previously had access to. You can use your discretion case by case. To rotate: file a bug, rotate, and update the private repo with new secret

Heroku

TODO

Dockerhub

TODO