Revoking User Access
Introduction
In the event of a cyber attack or similar malicious activity e.g. some user credentials are compromised, there may be a requirement to revoke user access on the Modernisation Platform (MP).
This page attempts to break down the various users/identities that exist on MP and explain what you would need to do to revoke access.
Individual IAM Users
MOJ Member Access
MP members who are MOJ employees access environments using AWS SSO which links GitHub Teams to various roles/environments.
Removing user access from GitHub Teams etc. is the responsibility of the relevant application team as explained here, however you could contact the Ops Engineering team who manage our GitHub organisation who will be able to revoke access.
Collaborator Access
Collaborator access is for non-MOJ employees who require access to AWS. These users are defined in the collaborators.json file.
Use this guide to remove a collaborator (NB the Terraform must be run locally as a superadmin user)
Modernisation Platform Team Access
MP team members access environments using AWS SSO and in very few circumstances via Superadmin access
Removing access for MP team members is documented here
We also have a testing-ci user, defined in code here which is used for automated tests.
It’s access is limited to the testing-test account and essential core resources. To remove this user raise a PR to remove the user or edit the access of the associated policy.
MOJ Master Users
There are a limited set of users who have access to the Root account (“MOJ Master”) for the organisation.
These users are defined in the root account repo
Any PRs raised to remove a users access would need to be approved by a member of operations-engineering or aws-root-account-admin-team.
Teams
GitHub Teams are linked to AWS environments via the environment/*.json files in the MP repo.
To remove a teams’ access/association with an AWS environment:
Edit the relevant
environment/*.jsonfile by removing the team name from thesso_group_namedefinition for the particular environment e.g."sso_group_name": "modernisation-platform",becomes"sso_group_name": "",Note that only one change to a
environment/*.jsonfile can be made per PR/run due to current constraints around how the automation works.Raise a PR and once merged the scheduled baseline job will run to update the access accordingly.
Automation Users (IAM roles/policies)
Member Roles
OIDC CI/CD Role
To allow automated access to MP member environments we provide an optional “OIDC CI/CD” role - modernisation-platform-oidc-cicd which is
explained in more detail here
To remove this role for member accounts through code:
Edit the relevant
environment/*.jsonfile by removing the team name from thegithub-oidc-team-repositoriesdefinition for the particular environment e.g."github-oidc-team-repositories": ["modernisation-platform"]becomes"github-oidc-team-repositories": [""]Note that only one change to a
environment/*.jsonfile can be made per PR/run due to current constraints around how the automation works.Raise a PR and once merged the scheduled baseline job will run to update the access accordingly.
CircleCI Role
Digital Prison Reporting make use of CircleCI for their pipeline. We manage a circleci_iam_role on their behalf which is defined in code here
Removing access would be as simple as raising a PR to either remove this code entirely or edit the permissions of the associated policy so that it has limited or no access.
MP Platform Management Roles
Here is a list of roles/identities that are used to manage the Modernisation Platform with links to the code that creates them. In the event of a compromise we would likely need to follow the steps in the next section to revoke permissions whilst the security incident is being investigated.
Bootstrap
github-actions- Role for GitHub ActionsModernisationPlatformAccess- A role that lives in all accounts (except the Modernisation Platform account) and is assumable by the ModernisationPlatform account with AdministratorAccess permissions. In the case of the testing-test account, this role is also assumable by thetesting-ciuserAWSSRTSupport- Role to allow AWS SRT to make AWS Shield Advanced and AWS WAF API calls on your behalf and to access your AWS WAF logs.MemberInfrastructureAccess- Role to define what members can manage in their environmentsMemberInfrastructureAccessUSEast- As above but for US-East regionMemberInfrastructureBedrockEuCentral- Role for members to access to AWS Bedrock
Core Logging
athena_lambda- Role for lambda access to athena
Core Network Services
dns- Role to allow ci/cd to update DNS records for ACM certificate validationread-log-records- Role to allow developer SSO user to read DNS records for ACM certificate validation for local plan
Core Shared Services
image-builder- Role to allow member developer SSO user to perform required shared services tasksLambdaInvoke- Role for EventBridge Scheduler to trigger Lambda Functionmember-shared-services- Role to allow member developer SSO user to perform required shared services tasks
Core VPC
member-delegation- A role that sits in the core-vpc accounts and can be assumed by relevant member accounts and ModernisationPlatform account in order to manage networking infrastructure (e.g. DNS, flow logs and EC2’s networking)member-delegation-read-only- Read only role for developer sso plans and for viewing via the console
Modernisation Platform
ModernisationPlatformGithubActionsRole- Modernisation Platform Github OIDC Rolemodernisation-account-limited-read- Limited Read Access in MP Account for Members and CImodernisation-account-terraform-state- Role allowing Modernisation Platform customers access to Terraform state backend resources
Urgent Disabling Access to IAM Roles
If there is an urgent need to restrict access related iam roles then consider the following two approaches:
Revoking IAM role temporary security credentials
To ensure all current sessions using the role are stopped the you can follow the guidance on AWS for revoking sessions permissions
This method attaches a new inline policy to the role that denies all permissions to all actions. It includes a condition that applies the restrictions only if the user assumed the role before the point in time when you revoke the permissions. If the user assumes the role after you revoked the permissions, then the deny policy does not apply to that user.
Disabling permissions for temporary security credentials
A more ‘belt and braces’ approach would be to follow the AWS guidance on denying access to all sessions associated with a role
This procedure denies permissions to all users that have permissions to assume a role with a policy like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*"
}
]
}
Risks/Caveats
This runbook describes how to revoke access through code which will permanently revoke access in the cleanest manner. In some cases this would not be the quickest way to revoke access.
Depending on the severity of the compromise there should be some thought around whether it would be better to temporarily use “clickops” to remove access before code changes can be released or whether there should be a dedicated mechanism (pipeline etc.) which can temporarily quarantine a user identity while a security incident is being investigated.
If any roles/identities related to the running of the MP platform are compromised then revoking access will likely remove our ability to make any further updates via code/pipeline so this action should not be taken lightly.