Table of contents

This documentation is intended for internal use by the GDS community.

AWS Account Management

Teams in GDS use multiple Amazon Web Services (AWS) accounts to:

  • enforce administrative isolation between workloads
  • minimize the impact of security breaches
  • isolate audit data in separate accounts

For example, by having separate AWS accounts for production and test workloads a team can restrict the security impact of a compromised credential.

To avoid users having to manage several sets of AWS credentials teams should use roles and cross-account access.

AWS describe this approach as the multiple account security strategy.

If you’re setting up a new AWS account for GDS and your team want to use cross-account access you should follow the guidance in this document using the gds-users account as your base account. See accessing aws accounts.

Advice on managing cross account access

Cross account access allows user accounts in one AWS account (the base account) to access resources in another AWS account (the target account).

Access to the resources within the target AWS account is controlled through IAM roles which are managed within that target AWS account.

The IAM roles are used to establish trust relationships between the target (trusting) AWS account and the base (trusted) AWS account.

It is the target AWS accounts responsibility to manage access to it’s resources. Although user accounts are managed within the base AWS account access to resources is managed by the target AWS account in which those resources reside.

Manage Access to Resources

Assume Role Diagram

The users exist in the base account and have permission to assume role into the target account.

The target account defines the roles (Data Analyst in this example) which the users in the base account can assume.

The Trust Relationship (Assume Role Policy)

The trust relationship describes which entities can assume the role (principles) and imposes conditions on how and when those entities can assume the role.

Principles

A principle can be a user account, an AWS account or a role. The principle entities are expressed as an AWS ARN.

It is strongly recommended not to trust an AWS account. Trusting an AWS account base account allows all of the entities within the base account to assume the role.

Conditions

Conditionals can be used to enforce the presence of MFA, restrict access to particular source IP addresses or restrict access to particular times of the day.

An example Trust Relationship policy
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::123456789012:user/example.user@digital.cabinet-office.gov.uk" },
    "Action": "sts:AssumeRole",
    "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
  }
}

Resource Permissions (Policies)

Access to resources are managed through IAM Policies, these can be custom or defined by Amazon. Roles should be designed around the permissions required to complete a task.