IAM

Last updated: Nov 4, 2026

---

Rationale

AWS IAM (Identity and Access Management) is the core AWS service to manage authentication and authorization in the platform. With it, Fluid Attacks has least privilege compliance for resource access.

These are the primary reasons why Fluid Attacks selected it and not other alternatives:

• It is a core AWS service. Thus, each entity must use it to get access to other AWS services.
• It complies with some certifications from ISO and CSA. Many of these certifications make sure that the entity uses best practices for secure cloud-based environments and information security.
• It supports users, groups, and roles. Thus, access management is fully flexible.
• It supports a wide range of policies, for example, identity-based or resource-based policies, permissions boundaries, service control policies, access control lists, and session policies.
• Policies use JSON. Thus, they are very easy to understand.
• Fluid Attacks builds policies with the actions that each policy must give access to. Each AWS service has its own actions.
• Many actions support condition keys. Thus, Fluid Attacks can customize authorization more.
• It integrates with Okta through the SAML protocol. Fluid Attacks can assign roles to Okta users and groups. Thus, it has full granularity and least privilege compliance for the AWS resources.
• It supports OIDC. Thus, the Kubernetes Cluster of Fluid Attacks can do actions in AWS, for example, make load balancers automatically when Fluid Attacks deploys applications.
• Fluid Attacks can write the resources as code with Terraform.

Alternatives

Usage

Fluid Attacks uses AWS IAM to manage these items:

• The development and production roles of its components. Each role has its own policies and permissions to give least privilege compliance. Developers assume these roles through Okta SAML. Trunk CI jobs assume the production roles through GitLab OIDC, and CI jobs on any branch can assume the development role. Kubernetes pods use the OIDC provider of the cluster.
• A SAML trust relationship between IAM and Okta. With it, developers and analysts can assume IAM Roles when they authenticate with their Okta credentials.
• S3 bucket policies, to give access only through CloudFront.
• KMS key policies, to set which users can use a key and which actions each of them can do.
• Service roles, that automated CI/CD processes assume to do only the actions that they must do in AWS.