Platform User Roles
The Modernisation Platform offers a selection of user roles to suit different use cases.
These are defined in code and supplied through single sign-on.
Modernisation Platform Roles
view-only
- Log into the console
- See resources and basic metadata. You cannot see the content of resources such as logs or S3 buckets.
read-only
- Log into the console
- Comprehensive read-only visibility of the AWS environment. As this role provides access to contents of S3 and others, it is designed for users for whom view-only is insufficient.
- Role makes use of AWS ReadOnly managed policy and is not at present configurable beyond that.
developer
The developer role is the stanard role used by teams deploying infrastructure onto the Modernisation Platform.
- Log into the console
- Read only access to resources including things like logs and S3 buckets
- View and Edit Secrets Manager secrets and Parameter Store values
- Create and rotate access keys for the application deployment CI user
- Connect to instances via SSM
- Start, stop and reboot EC2 instances
- Create and copy Snapshots
- Put and delete S3 objects
- Import certificates to ACM
- Switch roles to view shared resources
- Raise AWS Support cases
sandbox
The sandbox access can only be used on a development environment account.
- Log into the console
- Same console read and write permissions as the pipelines have
- This permission can only be attached to development accounts
- Once a week the account will be cleared with AWS Nuke and then rebuilt from Terraform
- The idea of sandbox access is that it gives you the freedom to experiment and modify things in the console to assist with creating your Terraform code.
Anything not in code will be lost at the end of the week.
migration
The migration role is a temporary role, given to assist with AWS managed migration services
- Log into the console
- Developer permissions
- Permissions to use AWS Migration services
- Once the migration is complete for an environment this role should be removed.
instance-management
The instance-management role is a role given to assist database administrators.
- Log into the console
- Read only access to resources including things like logs and S3 buckets
- Start, stop and reboot EC2 instances
- Create and copy Snapshots
- Connect to instances via SSM
- Active Directory permissions
instance-access
The instance-access role allows users limited access to EC2 instances.
- Log into the console
- Read only access to resources including things like KMS keys and secret values
- Manage instances using SSM
- Start and stop AWS Athena queries
security-audit
The security-audit role is used by security team members involved in auditing an application.
- Log into the console
- See resources and metadata useful to security operations teams and security audit teams
- Makes use of AWS managed SecurityAudit policy
reporting-operations
Created for a team supplying a reporting application on the Modernisation Platform.
- DMS Start, stop
- SQL Workbench
- Athena
- Glue
- Redshift
data-engineering
Created for data engineers to have developer permissions as well as glue and athena permissions all in one policy.
- Log into the console.
- Data engineering permissions.
fleet-manager
Created for teams with users who need to make use of AWS Fleet Manager to manage instances
- Log into the console
- Use AWS Fleet Manager for RDP-over-a-browser
administrator
This is a legacy role and will not be generally available.
- Full administrator access
s3-upload
Created for users who need to manage S3 buckets
- Log into the Console
- If the S3 bucket is in the same AWS account, you can view and manage the bucket directly through the S3 console interface.
- If the S3 bucket is located in a different AWS account, you will not see it directly in your console. Instead, use the following URL format to access the bucket:
https://eu-west-2.console.aws.amazon.com/s3/buckets/my-test-bucket?region=eu-west-2&bucketType=general&tab=objects
Replace my-test-bucket with the actual name of the bucket you wish to access.
Assigning Roles to Environments
Roles are assigned to environments through modifying the relevant environments/*.json file for an application.
For example, this snippet shows the addition of the example-role to another-example-team in example-application.json:
# example-application.json
{
...
"environments": [
{
"name": "development",
"access": [
{
"sso_group_name": "example-team",
"level": "developer"
},
>>> {
>>> "sso_group_name": "another-example-team",
>>> "level": "example-role"
>>> }
]
},
...,
}
Requesting a New Role
New roles can be requested through raising an issue on GitHub, although we recommend you discuss your use case with us on Slack via the #ask-modernisation-platform channel.