Identity and Access Management (IAM)

Rationale

AWS IAM is the core AWS service for managing authentication and authorization within the platform. It allows us to have least privilege compliance regarding resource access.

The main reasons why we chose it over other alternatives are the following:

It is a core AWS service, which means that one must use it to be able to access other AWS services.
It complies with several certifications from ISO and CSA. Many of these certifications are focused on granting that the entity follows best practices regarding secure cloud-based environments and information security.
It supports users, groups and roles, providing full flexibility regarding access management.
It supports a wide range of policies. They can be identity- or resource-based policies, permissions boundaries, service control policies, access control lists and session policies.
Policies are written using JSON, making them very easy to understand.
Policies are built based on the specific actions we want them to allow. Each AWS service has its own actions.
Many actions support condition keys, allowing further customization of authorization.
It integrates with Okta by using the SAML protocol. Roles can be assigned to Okta users and groups, giving us full granularity and least privilege compliance over the AWS resources.
It supports OIDC, allowing our Kubernetes Cluster to perform actions within AWS, like automatically creating load balancers when applications are deployed.
Resources can be written as code using Terraform.

Note: > GCP IAM and Azure RBAC are alternatives that did not exist at the time we migrated to the cloud. A review of each of them is pending.

We use AWS IAM for managing

development and production users in all our components (every user has their own policies and permissions in order to grant least privilege compliance; access keys for users are rotated on a daily basis);
a SAML trust relationship between IAM and Okta to allow developers and analysts to assume IAM Roles by authenticating with their Okta credentials;
S3 bucket policies, to allow access through Cloudflare only;
KMS key policies, to specify what users can use a key and what actions each of them can do;
service roles, to allow automated CI/CD processes to assume them, and execute specific actions within AWS.

You can access the AWS IAM console after authenticating on AWS.
Any changes to IAM infrastructure must be done via merge requests.
To learn how to test and apply infrastructure via Terraform, visit the Terraform Guidelines.