Skip to content

Latest commit

 

History

History
53 lines (33 loc) · 2.55 KB

rfc-075-managing-users.md

File metadata and controls

53 lines (33 loc) · 2.55 KB

Managing users on GOV.UK

Summary

Create a central repository of users in GOV.UK. Use that to verify that the correct people have access.

Context

Tech staff on GOV.UK can have access to dozens of things, like SSH access, GitHub organisation membership, and AWS accounts. When someone leaves access is revoked using a check list in a leavers card on the 2nd line Trello.

Problem

  1. The leavers process is slow and manual (and a bit boring). This means sometimes leavers aren't removed as quickly as we want.
  2. The process of removing people from access lists is based around making changes. There is no system in place that verifies that everyone who currently has access is actually allowed to. This means that if someone processes a leaver ticket and forgets a step, a user account can linger around forever.
  3. We'd like to use GitHub teams for authentication to our Jenkins. There are some concerns around that because it's very easy to add people to teams, and there is little visibility around the membership changes.

Proposal

We make a central list of GOV.UK users. We use this list to periodically verify that only the correct people have access. We do this by creating a Jenkins job that alerts Slack and Icinga if there are unexpected users with access to something.

This will make the leavers process more deterministic. It also prevents people from being added to the GitHub team outside our normal process.

There are a number of potential extensions to this, like adding an expiry date to the user accounts, which means we would get alerted when to remove a user (a concept that bob found in Gitlab).

Implementation

This is a proof of concept:

https://github.com/alphagov/govuk-user-reviewer/tree/prototype

It defines a list of users like this:

- username: johndoe
  github_username: john-code

The script in the repo will check:

  1. SSH access to (old) CI machines
  2. SSH access to mirrors
  3. SSH access to backup machines
  4. SSH access to integration
  5. Access to Jenkins
  6. Access to AWS in integration, staging & production (via Terraform)
  7. GitHub team membership (the GOV.UK team)

These aren't all the places access lists are defined (see the rest of the leaver ticket template), but it's a start. Once our credential repos are moved to public GitHub, production access can also be checked. Possibly we could create an endpoint for Signon to allow us to verify the admins/superadmins.