IAM

Rationale

AWS IAM  (Identity and Access Management) 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 ensuring 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 .

Alternatives

Usage

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 perform;
• service roles , to allow automated CI/CD  processes to assume them, and execute specific actions within AWS.