Cloud IAM Roles — AWS Roles, Azure Roles & GCP IAM Roles Guide

In this tutorial, you'll learn about Cloud IAM Roles. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Cloud IAM roles define sets of permissions that can be assumed by users, services, and applications across AWS, Azure, and GCP, enabling secure delegation and cross-account access without sharing long-term credentials.

What You Will Learn

The differences between managed and custom roles, how trust policies work in AWS, Azure RBAC role assignments at different scopes, and GCP IAM role hierarchies from basic to predefined to custom.

Why It Matters

Roles are the fundamental building block of cloud authorization. Understanding how each cloud defines, assigns, and evaluates roles is essential for designing least-privilege access at scale.

Real-World Use

DodaTech uses cross-account IAM roles in AWS to let developers in a sandbox account assume a read-only role in production. The trust policy restricts which accounts and users can assume the role and requires MFA. IAM policy conditions enforce source IP restrictions.

Role Architecture

flowchart LR
  subgraph AWS
    AWS_Role[IAM Role] --> Trust[Trust Policy\nWho can assume?]
    AWS_Role --> Perm[Permissions Policy\nWhat can they do?]
    AWS_Role --> Boundary[Permissions Boundary\nMaximum ceiling]
  end
  subgraph Azure
    AZ_Role["RBAC Role Definition\nActions / NotActions"] --> Assignment[Role Assignment\nPrincipal + Scope]
    Assignment --> Sub[Subscription Scope]
    Assignment --> RG[Resource Group Scope]
    Assignment --> Resource[Resource Scope]
  end
  subgraph GCP
    GCP_Role["IAM Role\nBasic / Predefined / Custom"] --> Binding[Policy Binding\nMember + Role + Condition]
    Binding --> Org[Organization Level]
    Binding --> Folder[Folder Level]
    Binding --> Project[Project Level]
  end
  
  style AWS_Role fill:#f90,color:#fff
  style AZ_Role fill:#390,color:#fff
  style GCP_Role fill:#09f,color:#fff

AWS IAM Roles

AWS IAM roles are assumed by trusted entities. The trust policy specifies who can assume the role. The permissions policy specifies what they can do.

# Create an IAM role for cross-account access
aws iam create-role \
  --role-name cross-account-reader \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::234567890123:root"},
      "Action": "sts:AssumeRole",
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }]
  }'

# Attach a managed policy to the role
aws iam attach-role-policy \
  --role-name cross-account-reader \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

# Create an instance profile role for EC2
aws iam create-role \
  --role-name ec2-app-role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "ec2.amazonaws.com"},
      "Action": "sts:AssumeRole]
    }]
  }'

# Create a service-linked role for a specific service
aws iam create-service-linked-role \
  --aws-service-name rds.amazonaws.com \
  --description "RDS service-linked role"

# List roles with their trust relationships
aws iam list-roles \
  --query 'Roles[*].[RoleName,Arn,CreateDate]' \
  --output table
# Output:
# ------------------------------------------------
# | RoleName            | Arn        | Created    |
# | cross-account-reader| arn:aws:...| 2026-06-24 |
# | ec2-app-role        | arn:aws:...| 2026-06-23 |
# ------------------------------------------------

Azure RBAC Roles

Azure RBAC uses role definitions that apply at specific scopes. Role assignments grant permissions to a principal at a scope.

# List built-in roles
az role definition list \
  --query "[].{Name:roleName, Type:roleType}" \
  --output table
# Output:
# Name                    Type
# Contributor             BuiltInRole
# Reader                  BuiltInRole
# Owner                   BuiltInRole
# Storage Blob Data Reader BuiltInRole

# Create a custom role scoped to a resource group
az role definition create \
  --role-definition '{
    "Name": "VM Operator",
    "Description": "Start, stop, and restart VMs",
    "Actions": [
      "Microsoft.Compute/virtualMachines/start/action",
      "Microsoft.Compute/virtualMachines/restart/action",
      "Microsoft.Compute/virtualMachines/deallocate/action]
    ],
    "NotActions": [],
    "AssignableScopes": ["/subscriptions/.../resourceGroups/prod-rg"]
  }'

# Assign the custom role
az role assignment create \
  --assignee user@dodatech.com \
  --role "VM Operator" \
  --scope "/subscriptions/.../resourceGroups/prod-rg"

# List role assignments
az role assignment list \
  --assignee user@dodatech.com \
  --query "[].{Role:roleDefinitionName, Scope:scope}" \
  --output table
# Output:
# Role          Scope
# VM Operator   /subscriptions/.../resourceGroups/prod-rg
# Reader        /subscriptions/...

GCP IAM Roles

GCP has three types of roles: basic (owner, editor, viewer), predefined (service-specific roles), and custom (fine-grained).

# List predefined roles for Compute Engine
gcloud iam roles list --filter "name:compute" --limit 5
# Output:
# name: roles/compute.admin
# name: roles/compute.networkAdmin
# name: roles/compute.securityAdmin
# name: roles/compute.viewer

# Create a custom role
gcloud iam roles create VMOperator \
  --project my-project \
  --title "VM Operator" \
  --description "Start, stop, and restart VMs" \
  --permissions compute.instances.start,compute.instances.stop,compute.instances.reset \
  --stage GA

# Bind the custom role to a service account
gcloud projects add-iam-policy-binding my-project \
  --member "serviceAccount:app-sa@my-project.iam.gserviceaccount.com" \
  --role "projects/my-project/roles/VMOperator"

# List role bindings
gcloud projects get-iam-policy my-project \
  --flatten="bindings[].members" \
  --format="table(bindings.role, bindings.members)" \
  --filter="bindings.role:VMOperator"
# Output:
# ROLE                          MEMBERS
# projects/my-project/roles/VMOperator  serviceAccount:app-sa@...

Cross-Account Role Patterns

All three clouds support cross-account access. AWS uses trust policies. Azure uses Lighthouse. GCP uses cross-project IAM bindings.

Common Mistakes

1. Using basic roles in GCP: Basic roles (owner, editor, viewer) grant broad permissions. Use predefined or custom roles instead.
2. Cross-account trust without MFA condition: Cross-account roles without MFA conditions are at risk if the source account is compromised. Always require MFA.
3. Roles without permissions boundaries: In AWS, a role without a permissions boundary is limited only by its permissions policy. Add boundaries for defense in depth.
4. Not scoping Azure role assignments: Assigning roles at the management group scope grants permissions to all subscriptions underneath. Scope assignments to the resource group or resource level.
5. Reusing roles across environments: A role for production should not be the same as a role for development. Create separate roles with environment-specific permissions.

Practice Questions

1. What is the difference between an IAM role and an IAM user in AWS?
2. How does Azure RBAC role assignment scope affect effective permissions?
3. What is the difference between GCP basic roles and predefined roles?
4. How do trust policies enable cross-account role assumption in AWS?
5. Why should production and development roles be separate?

Challenge

Design a role-based access architecture for a multi-team organization. Create AWS IAM roles for developers (read-only access in production, write access in development), operators (full access to compute resources in all environments), and security team (read access to all resources, IAM write access). Implement cross-account access from a shared services account to production accounts. Add MFA conditions on all cross-account trust policies. Write the equivalent role configurations in Azure and GCP.

FAQ