Cloud IAM Roles

Also Known As

TL;DR

Explanation

Identity and Access Management (IAM) roles are the primary mechanism cloud providers use to answer the question: who can do what to which resource? A role is a named collection of permissions (policy statements) that grants specific actions - like s3:GetObject or compute.instances.start - on specific resources, optionally constrained by conditions. Unlike a user, a role has no long-lived credentials of its own; a principal (a user, group, service account, or a workload such as an EC2 instance or Lambda function) assumes the role and receives short-lived credentials scoped to that role's permissions.

The core distinction across providers is between identity-based grants and the entity that holds them. On AWS you attach policies to roles and let services or users assume them via sts:AssumeRole. On GCP you bind a principal to a role at a resource, folder, or project level. On Azure you assign role definitions to principals at a scope. In all cases the effective permission set is the union of allow statements minus any explicit deny, evaluated against the requested action and resource.

Roles matter because they replace embedding static access keys in code or config. A workload that assumes a role gets rotating credentials automatically, so a leaked snapshot or log line does not hand an attacker a permanent key. Roles also make the principle of least privilege enforceable: you grant exactly the actions a service needs, scoped to exactly the resources it touches, rather than handing out broad admin.

The common failure mode is over-broad grants - wildcards on actions and resources - because they make the immediate task work and defer the security cost. Well-designed roles are narrow, use resource-level constraints and conditions, and are reviewed as access requirements change. Trust policies (who may assume a role) deserve as much scrutiny as permission policies, since a permissive trust relationship lets unintended principals inherit the role's power.

Common Misconception

Why It Matters

Common Mistakes

• Granting Action: "*" and Resource: "*" because it is faster than enumerating the exact permissions needed.
• Baking static access keys into application code instead of letting the workload assume a role.
• Writing permissive trust policies that let any principal in the account (or another account) assume a privileged role.
• Reusing one broad role across many unrelated services instead of scoping a role per workload.
• Never reviewing or pruning roles, so permissions accumulate long after the need disappears.

Avoid When

• Never over-grant just to unblock a deploy - a temporary wildcard almost always becomes permanent.
• Do not use a single shared role for many distinct workloads when each has different access needs.
• Avoid long-lived static access keys where the platform supports assumable roles or workload identity.

When To Use

• Granting a cloud workload (EC2, Lambda, container, service account) access to resources without embedding credentials.
• Enforcing least privilege by scoping distinct roles per service and per environment.
• Enabling cross-account or federated access through scoped trust policies and short-lived credentials.

Code Examples

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}
// Over-broad: this role can do anything to anything.
// A leaked credential using it compromises the whole account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadAppUploads",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-app-uploads/*",
      "Condition": {
        "StringEquals": {"aws:RequestedRegion": "eu-west-1"}
      }
    }
  ]
}
// Scoped: only object read/write on one bucket, one region.
// Workload assumes this role and gets short-lived credentials.

Tags

Related Terms

References

• https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html
• https://cloud.google.com/iam/docs/understanding-roles
• https://learn.microsoft.com/en-us/azure/role-based-access-control/overview
• https://cwe.mitre.org/data/definitions/732.html