AWS account setup
  • AWS account setup
  • How to
    • How to log in to the AWS console
    • How to get credentials for working locally, e.g. the AWS CLI
    • How to select a role in the AWS CLI
    • How to get credentials for staff who aren't developers
  • Users, IAM roles, accounts, and so on
    • Introduction
    • What are our AWS accounts?
    • What is an initial role?
    • What are our standard roles?
  • Networking
    • Our VPC setup
Powered by GitBook
On this page
  1. Users, IAM roles, accounts, and so on

Introduction

PreviousHow to get credentials for staff who aren't developersNextWhat are our AWS accounts?

Last updated 2 months ago

This is how you get to stuff inside our AWS accounts:

1. A user logs in through AWS Identity Center. All our AWS access is tied to single-sign on accounts -- we manage our users with AWS Identity Center and Azure Entra ID (Active Directory) rather than in AWS.

2. The user assumes an "initial role" inside AWS. This is an IAM role, where is the AWS service for managing permissions and access to AWS resources.

This role can't do anything except assume other roles.

3. The user assumes a more specific role, which has permission to do whatever they need to do. There are lots of these roles, each of which has fairly specific permissions. There are different roles for different accounts (e.g. storage, dlcs, workflow) and for different permission levels within each account (e.g. read-only, admin).

This variety acts as a guard rail -- you pick a role for the current task, which allows you to do what you need to do, but you can't accidentally break something completely different.

For example, if you're changing something in the catalogue API, you'd pick a role that lets you modify the catalogue API resources. That role wouldn't have permission to modify the storage service, so there's no risk of you breaking it inadvertently.

4. The user does whatever is allowed by the role they've picked.

IAM