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

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 the 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/*.json file by removing the team name from the sso_group_name definition for the particular environment e.g. "sso_group_name": "modernisation-platform", becomes "sso_group_name": "",
Note that only one change to a environment/*.json file 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/*.json file by removing the team name from the github-oidc-team-repositories definition 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/*.json file 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 and Youth Justice App Framework make use of CircleCI for their pipeline. We manage a circleci_iam_role on their behalf which is defined in code in the following files: dpr/iam.tf and yjaf/iam.tf.

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 - OIDC role (via the shared OIDC module default role name) used for CI/CD from modernisation-platform and modernisation-platform-environments; can read/write specific Terraform state paths and decrypt KMS for those operations.
github-actions-plan - OIDC role for modernisation-platform-environments plan workflows in member accounts; read-only Terraform state access, lock-file updates, KMS decrypt and sts:AssumeRole into read-only/delegation roles.
github-actions-apply - OIDC role for modernisation-platform-environments apply workflows in member accounts; scoped by GitHub OIDC environment claim (environment:${terraform.workspace}*) and uses member apply permissions.
github-actions-testing - OIDC role in testing-test used by multiple MP Terraform module repositories for integration tests; includes ReadOnlyAccess plus targeted assume-role/state/KMS permissions.
github-actions-provider-role - OIDC bootstrap role for testing-test used to set up GitHub OIDC provider access for automation in that account.
github-actions-dev-test - OIDC role for development/test member environments from the modernisation-platform repo; has AdministratorAccess plus cross-account assume-role and Terraform state permissions.
github-actions-environments-read-only - OIDC role for modernisation-platform-environments with read-only style access used for sprinkler environment workflows.
github-actions-environments-dev-test - OIDC role for non-production sprinkler workflows with controlled write access to specific Terraform state paths.
github-actions-nuke - OIDC role for sandbox cleanup automation from modernisation-platform main branch.
github-actions-securityhub-insights - OIDC role for Security Hub insight creation/update/reporting from modernisation-platform main branch.
github-actions-iam-hygiene - OIDC role used to discover and clean up IAM user credentials (for example disabling/deleting access keys and login profiles) in member/member-unrestricted accounts.
AWSSRTSupport - 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.
ModernisationPlatformAccess - A role that lives in all accounts (except the Modernisation Platform account) and is assumable by the ModernisationPlatform account with AdministratorAccess permissions.
MemberInfrastructureAccess - Role to define what members can manage in their environments
MemberInfrastructureAccessUSEast - As above but for US-East region
MemberInfrastructureBedrockEuCentral - Role for members to access to AWS Bedrock

The MemberInfrastructure* and ModernisationPlatformAccess roles are generally assumed by Terraform providers in automated pipelines rather than directly by users. A common assume-role chain for automated deployments is:

github-actions* -> MemberInfrastructureAccess* or ModernisationPlatformAccess

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 validation
read-log-records - Role to allow developer SSO user to read DNS records for ACM certificate validation for local plan
github-actions-vpn-environment-check - OIDC role from modernisation-platform-environments to read VPN connection state.
github-actions-vpn-maintenance - OIDC role from modernisation-platform-environments to perform VPN tunnel replacement/maintenance.

Core Shared Services

image-builder - Role to allow member developer SSO user to perform required shared services tasks
LambdaInvoke - Role for EventBridge Scheduler to trigger Lambda Function
member-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 Role
modernisation-account-limited-read - Limited Read Access in MP Account for Members and CI
modernisation-account-terraform-state - Role allowing Modernisation Platform customers access to Terraform state backend resources
github-actions-plan - OIDC plan role in the MP account used by multiple platform repositories, with KMS/secrets access, read-state permissions and controlled cross-account assume role.
github-actions-apply - OIDC apply role in the MP account (main branch) with AdministratorAccess and explicit deny on interactive IAM login operations.
github-actions-read-secrets - OIDC role for selected repositories to read specific secrets used by platform automation.

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.

Last reviewed: 24 April 2026Review status: ✓ Up to dateOwner: #modernisation-platformSource: View source on GitHub

Was this page useful?