How cloud IAM works at the level of subjects, actions, resources, and conditions — comparing RBAC, ABAC, and JIT access — and the access control mistakes that appear in almost every cloud audit.
Sign in to mark this article as read and track your progress.
In traditional networks, a firewall defined the security perimeter. In cloud, the firewall is still relevant — but the real perimeter is identity. Every action in AWS, Azure, or GCP is an authenticated API call. Every breach ultimately involves either stolen credentials or an overprivileged identity. Mastering IAM is mastering cloud security.
A cloud IAM policy answers four questions:
| Element | Question | Example |
|---|---|---|
| Subject (Principal) | Who is making the request? | IAM user, IAM role, AWS service, federated identity |
| Action | What are they trying to do? | s3:GetObject, ec2:RunInstances, iam:CreateUser |
| Resource | What are they acting on? | arn:aws:s3:::my-bucket/* |
| Condition | Under what circumstances is this allowed? | Source IP, MFA authenticated, time of day |
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::company-data/reports/*",
"Condition": {
"Bool": {"aws:MultiFactorAuthPresent": "true"},
"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
}
}]
}
This policy allows reading and writing only to reports/ within company-data bucket, only from a specific IP range, and only when MFA is active. Contrast with the common anti-pattern: "Action": "*", "Resource": "*" — which grants full admin access to everything.
Users are assigned roles (Developer, ReadOnly, DBAdmin), and roles carry permissions. Simple to manage at small scale; becomes unwieldy when hundreds of roles accumulate.
Cloud implementation: AWS IAM Roles and Groups; Azure RBAC; GCP IAM roles
Access decisions are made based on attributes of the requester, the resource, and the environment. Example: Allow access to any resource tagged Environment:Production only by principals tagged Team:Ops.
Cloud implementation: AWS IAM tag conditions; Azure ABAC; Google Cloud IAM conditions
ABAC scales better than RBAC in large organisations — new resources automatically inherit correct policies through tag matching without manual role assignment.
Permanent privileged access is eliminated. When privileged access is needed, it is granted temporarily (minutes to hours), with full audit logging, and automatically revoked after the session.
Cloud implementation: AWS IAM Identity Center temporary elevation; Azure PIM (Privileged Identity Management); GCP PAM (Privileged Access Manager)
JIT access is the gold standard for privileged operations. No standing admin access means compromised credentials for a regular user cannot be used for persistent privileged actions.
These mistakes appear in virtually every cloud security assessment:
1. Wildcard resource in sensitive policies
"Resource": "*" on iam:* actions means any IAM operation on any resource. This is full administrator access, often unintentionally granted.
2. No MFA enforcement Root account and IAM users with console access not requiring MFA. A single phished credential gives full access.
3. Overprivileged EC2 instance roles
An application server attached to a role with s3:* on all buckets, iam:PassRole, or sts:AssumeRole with no restriction. The SSRF-to-IMDS chain turns this into a critical finding.
4. Inline policies instead of managed policies Inline policies are harder to audit and reuse. They often contain unique one-off permissions that accumulate privilege over time without review.
5. Cross-account trust with Principal: *
A role trust policy allowing any AWS account to assume it gives any AWS customer on the planet potential access.
6. Access keys for long-term use IAM access keys used for months or years without rotation. Use IAM roles and temporary credentials (STS) instead of long-term access keys wherever possible.
7. No resource-based boundary policies No Service Control Policies (SCPs) at the organisation level to prevent accounts from disabling CloudTrail, removing MFA requirements, or accessing sensitive services.
The principle of least privilege: grant every identity the minimum permissions required to perform its function, for the minimum time required.
In practice:
Cloud IAM is simultaneously the most powerful and most misunderstood security control in cloud environments. RBAC for structure, ABAC for scale, JIT for privileged operations, and least privilege as the governing principle — these four together eliminate the identity-layer risk that drives the majority of cloud breaches.