There are currently four AWS accounts we use:
The login email addresses for the root users of these accounts are listed in the credentials repo in the
file. In general, and following best practices, these root users are never normally used. As
such, we don’t store the passwords for them. If you need to login as a root user you should trigger a password reset.
The MFA codes for the accounts are distributed among various team members.
The main account is used for creating objects that are not direct attributes of an environment.
For example our Jenkins EC2 instance is environmentally agnostic because it has jobs that operate on preview, jobs that operate on staging and production, and jobs that operate freely of any DM environment. Our AWS users are actually environmentally agnostic too. They should be able to access the different environments. But they are not tied to one or the other.
As well as the Jenkins EC2 and our aws users, other AWS objects we create in the main account are:
SOPS AWS KMS keys (for decrypting the credentials in the credentials repo)
Route53 DNS apex records for the marketplace.team DNS zone
The Development account houses the infrastructure related to the preview environment of Digital Marketplace.
The Production account houses the infrastructure related to the staging and production environment of Digital Marketplace.
These include; Route53 DNS records for subdomains (e.g. www), S3 buckets, dedicated users for handling logging, cloudwatch log groups, and IAM policies that allow users from the main account to operate on objects in the Development and Production accounts.
The backups account houses two S3 buckets that contain encrypted and compressed copies of our database. For more on how they get there see the backups section of the manual.
A separate account is necessary because it is impossible to have MFA delete and a lifecycle deletion policy on the same bucket. To get around this we created an entirely new account protected by MFA, containing a bucket with a lifecycle deletion policy.
All users have access to the main AWS account. Using the AWS console is IP restricted (GDS office IPS) and MFA is mandatory. Other accounts can be accessed by switching roles.
All passwords have to comply with the following rules:
at least 12 characters long
contains at least one uppercase letter
contains at least one lowercase letter
contains at least one number
You can set up MFA the following way:
IAM -> Users -> [your user] -> Security credentials tab -> Assigned MFA device -> edit
After adding the MFA device you need to log out and log in again to have access to the services you are allowed to manage
You can switch roles by clicking on the top right on the <username>@account menu and choosing the ‘Switch Role’ action. You’ll also find the last several roles you used in there.
If needed you can construct a switch role url in the following format:
To switch back to your original user click on the coloured role button on the top right and choose ‘Back to <username>’.
You can generate access key the following way:
IAM -> Users -> [your user] -> Security credentials tab -> Create access key
For local use it’s recommend to save your keys to ~/.aws/credentials in the following format:
[default] aws_access_key_id=AKIAI... aws_secret_access_key=Kaet7Zae...
Default credentials give you the permissions to use S3 development bucket when running apps locally and allow you to switch to different roles depending on your user groups.
An IAM role is similar to a user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have any credentials (password or access keys) associated with it. Instead, if a user is assigned to a role, access keys are created dynamically and provided to the user.
Roles allow you to switch between different AWS accounts. 12-digit account number in the role_arn is the target AWS account number the role is defined on.
If you need to switch to a different role you can define additional profiles in ~/.aws/config.
SOPS credentials access
This role has to be used for decrypting files in the digitalmarketplace-credentials repository.
[profile sops] source_profile = default mfa_serial = arn:aws:iam::398263320410:mfa/<IAM username> role_arn = arn:aws:iam::398263320410:role/sops-credentials-access
These roles are needed to run Terraform or CloudFormation scripts against main, development (preview) and production (staging and production) accounts.
[profile development-infrastructure] source_profile = default mfa_serial = arn:aws:iam::398263320410:mfa/<IAM username> role_arn = arn:aws:iam::381494870249:role/infrastructure [profile production-infrastructure] source_profile = default mfa_serial = arn:aws:iam::398263320410:mfa/<IAM username> role_arn = arn:aws:iam::050019655025:role/infrastructure [profile main-infrastructure] source_profile = default mfa_serial = arn:aws:iam::398263320410:mfa/<IAM username> role_arn = arn:aws:iam::398263320410:role/infrastructure
You may, and likely will, have several sets of AWS credentials that you use for different tasks.
Your sops credentials allow you to decrypt the files in the digitalmarketplace-credentials repo for example
Using the <ENVIRONMENT>-infrastructure roles will allow you to run terraform (see above)
Profiles are a way of grouping credentials and referring to them by name.
When using profiles you only need to set the
variable for your command/ applications:
Some of the tools we use don’t have built-in support for assuming roles, so you need to provide them with temporary credentials by prefixing the command with aws-auth:
Using SOPS to decode secrets:
AWS_PROFILE=sops aws-auth sops -d logins.enc
Running terraform (such as is done in the digitalmarketplace-aws Makefile):
AWS_PROFILE=development-infrastructure aws-auth terraform get AWS_PROFILE=development-infrastructure make plan AWS_PROFILE=development-infrastructure make apply