Rules for getting production access
In the GOV.UK programme we restrict access to production systems for new or returning developers, SREs, and technical architects. We do so to defend against accidental mistakes and to provide time for people build knowledge in how to interact with our production systems safely. Note we have separate processes to protect against malicious activity, for example security clearance, probation, building secure systems with audibility etc.
Types of production access
We have two types of production access:
We have a spreadsheet documenting the full list of permissions for both access levels.
Production Deploy access
This level of access allows engineers to deploy code but not administer admin related systems. Access includes:
- Permission to deploy apps via the GOV.UK Production Deploy Github team
- Permission to merge pull requests in continuously deployed applications
- Read-only access to logging systems such as Logit, etc.
- Read-only access to dashboards in staging and production, such as the Argo CD web UI.
- AWS readonly access via the
role_user_user_arnsrole in Staging and Production - “Normal” role in to GOV.UK Signon on Staging and Production (with app permissions granted as needed)
The steps above are outlined in the GOV.UK Production Deploy template Trello card, which can be copied to your team’s board and carried out by developers. You can ask 2nd line for help if you have any access issues.
When you get Production Deploy access
Access can be granted to both civil servants and contractors as needed, at the discretion of a “sponsor”: either the engineer’s (civil servant) tech lead, or a GOV.UK Senior Tech member.
Before approving access, the sponsor should ensure that the engineer:
- has the required level of security clearance (BPSS)
- is aware of our processes and standards around code review
- understands the responsibilities that releasing code brings with it
- knows how to roll back to an older release if there are any issues
- knows how to get help from someone with more access if they need it
To grant access, the sponsor should follow the steps in the “GOV.UK Production Deploy” access template card.
Note that a technologist apprentice is limited to Production Deploy access. However, if they are confident and want to take on a 2nd line shift as a Secondary, they can follow the Production Admin access steps (at their Line Manager’s discretion).
Production Admin access
Gives:
- Write access to Argo CD in staging and production via the GOV.UK Production GitHub team
- Privileged AWS Access in Production, Staging and Tools environments (via the
role_admin_user_arnsrole) - Google Cloud Platform (GCP) access to role to manage static mirrors and DNS
- Signon “Super Admin” access in production
engineerand “Access all services” permissions in Fastly- Sentry “Admin” role to administer teams and projects
When you get Production Admin access
- You have a minimum of BPSS security clearance (blue building pass), AND
- You have passed your probation period, AND
- You have completed the Production Admin Preparedness checklist, covering the learning objectives below, and have had your form response reviewed by someone in Senior Tech.
To grant access, the senior tech person should follow the steps in the “GOV.UK Production Admin” access template card.
Production Admin learning objectives
A new starter/engineer will be expected to work through the following checklist in order to ‘qualify’ for production admin access:
- The different parts of the GOV.UK technical stack (CDN, frontends, publishing apps, etc). E.g. by attending an “Introduction to GOV.UK Technical Architecture” session (or watching the recording).
- The deployment pipeline - how code gets from your machine to running on production. E.g. by reading the deployment docs, and learning on the job.
- The incident management process. E.g. by reading through the So, you’re having an incident doc and completing the incident preparedness quizzes.
- Best practices around the principle of least privilege, how to safely debug production issues, and how to work with credentials and accounts. E.g. by pairing with another developer to practise a drill on your product team.
Temporarily revoking access
If you’re absent more than 6 weeks, your access should be revoked.