Cloud IAM Least Privilege on AWS, Azure and GCP: A Defender's Guide

In the cloud, identity is the new perimeter. Most impactful cloud breaches do not begin with an exotic exploit; they begin with an over-permissioned identity — a leaked access key, a compromised service principal, or an application role that can do far more than its job requires. Least privilege, the principle that every identity should hold only the permissions it actually needs, is therefore the single highest-leverage control you can apply. This defender-focused guide explains how the IAM models of AWS, Azure and GCP work, how over-permissioning turns a small foothold into a full compromise, and how to detect and harden your way to least privilege without breaking workloads.

Why least privilege is the core cloud control#

Cloud platforms make it trivially easy to grant broad access and surprisingly hard to know what access is actually used. Under the shared responsibility model, the provider secures the infrastructure, but you are responsible for configuring identity and access — and misconfiguration here is consistently among the top causes of cloud incidents. The reason least privilege matters so much is blast radius: when an identity is compromised, the damage is bounded by what that identity can do. A tightly scoped role turns a stolen credential into a minor event; a wildcard-laden admin role turns the same theft into a data-exfiltration and ransomware scenario.

The IAM models: AWS, Azure and GCP compared#

The three major clouds share concepts but differ in mechanics, and defenders need the vocabulary. AWS uses JSON policies attached to users, groups and roles, evaluated as an allow/deny with explicit deny always winning; workloads assume roles for temporary credentials. Azure uses role-based access control (RBAC) with role definitions assigned at a scope (management group, subscription, resource group or resource), and identities are users, groups, service principals and managed identities in Entra ID. GCP binds roles (primitive, predefined or custom) to members via IAM policies on a resource hierarchy (organisation, folder, project, resource), with policy inheritance flowing downward. In all three, permissions accumulate and inheritance can grant far more than intended.

How over-permissioning enables escalation#

Understanding escalation conceptually helps you prioritise hardening. The classic pattern is an identity that holds a permission letting it grant itself or assume more powerful permissions. In AWS this includes the ability to pass a privileged role to a service, or to modify IAM policies; in Azure it includes rights to assign roles or manage service principal credentials; in GCP it includes the ability to act as a more privileged service account or set IAM policy. None of these require a software vulnerability — they are the intended behaviour of an over-broad grant. The defensive takeaway is that permissions which manage other permissions, or which let one identity become another, are the crown jewels and must be tightly restricted and closely watched.

Common over-privilege pitfalls#

Certain patterns show up in nearly every cloud audit. Wildcards such as Action: "*" or Resource: "*" grant sweeping rights that no workload actually needs. Broad managed roles like account-wide administrator or owner attached to service identities are a frequent finding. Long-lived static keys that never expire and are copied into config files or CI systems are a leak waiting to happen. Inherited privilege from a role granted high in the hierarchy silently applies to everything below it. And unused permissions accumulate because grants are added for a one-off task and never removed. Each of these expands blast radius for no operational benefit.

Detection: mining your access logs#

Every provider records identity activity, and this telemetry is the foundation of detection. In AWS, CloudTrail logs API calls; in Azure, the Entra ID sign-in and audit logs plus Activity Log; in GCP, Cloud Audit Logs. Feed these into your SIEM and build detections for high-signal events: use of root or global-admin accounts, creation of new access keys or service principal secrets, IAM policy modifications, role assignments that grant privileged roles, and access from unusual locations or impossible-travel patterns. Alert on the first use of a permission an identity has never exercised, and on any identity suddenly performing IAM management actions. These are the signals that a foothold is being expanded.

Detection: finding unused and risky access#

Beyond real-time alerting, run continuous access reviews using the platforms' own analysis tools. AWS IAM Access Analyzer generates least-privilege policy suggestions from CloudTrail history and flags resources shared externally; the last-accessed data shows permissions and services an identity has not used. Azure provides Entra Permissions Management and access reviews to surface unused assignments; GCP offers the IAM Recommender which proposes tighter roles based on observed usage. Treat every unused permission, every externally shared resource, and every dormant privileged identity as a finding to remediate. The gap between permissions granted and permissions used is your excess attack surface, quantified.

Mitigation: designing least-privilege access#

Move toward least privilege methodically rather than by hand-editing policies under pressure. Start from deny and add only what usage data proves is needed, using the recommender tools above to right-size roles. Prefer predefined or custom roles scoped to specific resources over wildcards and built-in admin roles. Grant at the narrowest scope that works — a single resource group or project rather than the whole subscription or organisation. Replace long-lived keys with short-lived, federated credentials: workload identity federation and OIDC let CI systems and workloads obtain temporary tokens without storing secrets. Separate human and machine identities, and never let a person and an automation share one credential.

Mitigation: guardrails and boundaries#

Individual policies are not enough; you need organisation-wide guardrails that cap what any policy can grant. AWS Service Control Policies set the maximum permissions for accounts in an organisation, and permission boundaries cap what a delegated admin can grant to the identities they create. Azure uses Azure Policy and management-group scoping to enforce constraints; GCP uses Organisation Policy constraints. Layer these so that even a mistaken or malicious broad grant cannot exceed the guardrail. Add just-in-time elevation — Azure Privileged Identity Management, or approval-gated temporary role assumption elsewhere — so standing privileged access is minimised and every elevation is logged and time-boxed.

Common pitfalls#

Least-privilege programmes fail in predictable ways. Chasing zero findings by over-restricting and breaking workloads causes teams to revert to broad grants in frustration, so use usage data and stage changes. Tightening human roles while ignoring machine identities misses the larger population — service accounts and managed identities usually outnumber people and are more likely to be over-privileged. Cleaning up permissions once and never re-reviewing lets privilege creep back as new tasks add grants. Leaving root and break-glass accounts without MFA and monitoring negates everything else. And forgetting that explicit deny and guardrails override allows, or misordering evaluation logic, leads to policies that do not behave as written.

Hardening checklist#

1. No wildcard actions or resources on production identities; scope every role to specific resources. 2. No account-wide admin or owner on service identities; use least-privilege predefined or custom roles. 3. Long-lived static keys replaced by short-lived federated credentials; remaining keys rotated and inventoried. 4. Organisation guardrails in place (SCPs / Azure Policy / Org Policy) plus permission boundaries. 5. Just-in-time elevation for privileged access; standing admin minimised; root/break-glass under MFA and alerting. 6. Continuous access review with Access Analyzer / Permissions Management / IAM Recommender; unused permissions removed. 7. Audit logs (CloudTrail / Entra logs / Cloud Audit Logs) centralised in the SIEM with detections on IAM changes and anomalous access. 8. Human and machine identities separated; external resource sharing reviewed.

FAQ: does least privilege slow teams down?#

Done badly it can, but done well it does not, and the trade-off strongly favours least privilege. The mistake is hand-tightening policies through guesswork, which breaks workloads and frustrates engineers. The modern approach uses observed-usage data — the recommender and last-accessed tools — to propose roles that match what workloads actually do, so you remove excess without removing function. Pair that with self-service just-in-time elevation for the rare cases that need more, and teams get the access they need on demand while standing privilege stays low. The result is both safer and, because access is predictable and reviewable, often less friction than ad-hoc broad grants.

FAQ: where should I start across three clouds?#

Start where blast radius is largest, not where it is easiest. Inventory your most privileged identities first — anything with admin, owner, or the ability to manage IAM or assume other identities — because those are the escalation crown jewels. Secure root and global-admin accounts with MFA and remove standing use. Then eliminate long-lived keys in favour of federation, since leaked static credentials are the most common initial access. Only then work through right-sizing the long tail of workload roles using each platform's recommender. This order retires the highest-impact risks first and gives you quick, defensible wins across AWS, Azure and GCP alike.

Conclusion#

Least privilege is not a one-time cleanup but an operating discipline, and in the cloud it is the control that most directly limits how bad a compromise can get. The mechanics differ across AWS, Azure and GCP, but the defensive playbook is the same everywhere: understand the IAM model, hunt down wildcards and over-broad roles, replace long-lived keys with short-lived federation, cap everything with organisation guardrails, and use each platform's usage analysis to right-size continuously. Wrap it in centralised audit logging with detections on identity abuse, and you turn IAM from your biggest exposure into a monitored, bounded and defensible perimeter.