Skip to main content

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:

  1. It is a core AWS service, which means that in order to be able to access other AWS services, one must use IAM.
  2. 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.
  3. It supports users, groups and roles, providing full flexibility regarding access management.
  4. It supports a wide range of policies. They can be identity-based, resource-based, permissions boundaries, service control policies, access control lists and session policies.
  5. Policies are written using JSON, making them very easy to understand.
  6. Policies are built based on the specific actions we want them to allow. Each AWS service has its own actions.
  7. Many actions support condition keys, allowing to further customize authorization.
  8. 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.
  9. It supports OIDC, allowing our Kubernetes cluster to perform actions within AWS like automatically creating load balancers when applications are deployed.
  10. Resources can be written as code using Terraform.

Alternatives#

  1. GCP IAM: It did not exist at the time we migrated to the cloud. Pending to review.
  2. Azure RBAC: It did not exist at the time we migrated to the cloud. Pending to review.

Usage#

We use AWS IAM for:

  1. Managing development and production users for all our products. Every user has its own policies and permissions in order to grant least privilege compliance. Access keys for such users are rotated on a daily basis.
  2. Managing a SAML trust relationship between IAM and Okta in order to allow developers and analysts to assume IAM Roles by authenticating with their Okta credentials.
  3. Managing S3 bucket policies for only allowing access through Cloudflare.
  4. Managing KMS key policies for specifying what users can use a key and what actions each of them can do.
  5. Managing service roles for allowing automated CI/CD processes to assume them and executing specific actions within AWS.

Guidelines#

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