IAM and Least Privilege

Cloud breaches almost always start at identity. A wildcard policy, a leaked access key, an overprivileged role. Doing IAM well is the highest-leverage security investment you can make.

The Three Cloud IAM Models

Despite the different terms, the same patterns apply: principals (who) get permissions (what they can do) on resources (where) — bounded by guardrails.

Least Privilege in Practice

Least privilege does not mean "deny everything and add as needed." That breaks production. It means:

1. Start with a narrow scope (specific resource or prefix, not *).
2. Pick action verbs that match what the workload actually does.
3. Apply conditions where useful (region, MFA, source IP, resource tag).
4. Iterate using access analyzer / activity logs to find unused permissions.

Bad:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

Better:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::reports-prod/uploads/*",
  "Condition": {
    "Bool": { "aws:SecureTransport": "true" },
    "StringEquals": { "aws:RequestedRegion": "eu-west-1" }
  }
}

Roles, Not Users

Long-lived users with access keys are the single biggest cloud-breach vector — keys leak in commits, CI logs, or compromised laptops. Replace them with roles.

• Workload identity — EC2 instance profiles, EKS IRSA, Lambda execution role; Azure Managed Identities; GCP attached service accounts. The workload gets short-lived tokens automatically.
• Federation for humans — connect Okta / Entra ID / Google Workspace to your cloud and use SSO. Each engineer gets STS / Azure AD / Workforce Identity tokens that expire in hours.
• Federation for CI/CD — OIDC trust between GitHub Actions / GitLab / Bitbucket and the cloud. No static credentials anywhere.

Eliminate Static Credentials Where You Can

Identity Hygiene Checklist

• Root / Global Admin: MFA, hardware token, used only in break-glass.
• Every human: federated, MFA-enforced, no console password in cloud.
• Every workload: role, not key. Token TTLs < 1 hour.
• No *:* outside of break-glass roles.
• Quarterly access review; remove unused permissions and dormant identities.
• Centralised audit logs of every IAM change.
• Alerts on root login, IAM policy creation, access key creation.

Guardrails: Defence in Depth

Even with great IAM, mistakes happen. Org-level guardrails prevent the worst.

• AWS Service Control Policies (SCPs) — applied to OUs/accounts. Cap the maximum permission. "No account in the prod OU may disable CloudTrail." Even an admin cannot.
• Azure Policy — declarative rules at management-group, subscription, or resource-group scope. "All storage accounts must have private endpoints," with audit or deny effect.
• GCP Organization Policy — boolean and list constraints. "iam.disableServiceAccountKeyCreation" prevents creating downloadable keys anywhere in the org.

These do not replace IAM; they backstop it. Even a compromised admin role cannot punch through a deny-by-policy at the org level.

Privileged Access Management

Some operations are unavoidable but dangerous: production database access, IAM changes, key rotations. Treat them specially:

• Just-in-time access — Azure PIM, AWS IAM Identity Center session policies, GCP just-in-time recommender. Engineers request elevated access for a few hours with a reason logged.
• Break-glass accounts — sealed credentials accessible only in genuine emergencies, with alerting on use.
• Approval workflows — sensitive role assumptions require a second engineer's approval (Slack approval bot, Datadog Workflows, ServiceNow).

Verifying Least Privilege

• AWS IAM Access Analyzer reviews CloudTrail and produces minimal policy suggestions.
• Azure Activity Log + PIM access reviews highlight unused permissions.
• GCP Recommender suggests removing unused roles automatically.
• Third-party tools (Wiz, Prisma, Tenable, Permiso) cover all three clouds and identity providers in one view.

Common Exam Traps

• Choosing a role over an access key for an EC2 / VM workload — always the right answer.
• SCPs do not grant permissions; they cap them. An action must be allowed by both IAM and SCP to be effective.
• Cross-account access is via assume-role, not by sharing credentials.
• Conditions like aws:MultiFactorAuthPresent or aws:SourceVpc are powerful and frequently appear in exam scenarios.
• Managed Identities and Workload Identity Federation eliminate the need to store any credential.

If only one security investment is possible, fix identity. The rest of the course assumes you have done so.