Cloud IAM

Every cloud IAM system evaluates the same four elements per API request: a principal (human user, group, federated identity or workload identity such as an AWS IAM role, a Google Cloud service account or an Azure managed identity), an action (a service-namespaced operation like s3:GetObject), a resource (an ARN in AWS, a full resource name in Google Cloud, a scope path in Azure) and optional conditions (source network, MFA present, tags, time). Authentication of the caller comes first, via a signed request or an OAuth 2.0 access token; authorisation then runs on every call, and the default outcome is an implicit deny.

The combination logic differs by provider. In AWS an explicit Deny in any applicable policy always wins; otherwise the request needs an Allow from an identity-based or resource-based policy, and it must also fall within every ceiling that applies: Organizations service control policies, permissions boundaries and session policies grant nothing themselves but cap what can be granted. Cross-account access needs an Allow on both sides. Google Cloud binds roles (bundles of permissions) to principals in allow policies at organisation, folder, project or resource level, inherited downwards as a union, with separate deny policies and IAM Conditions to restrict. Azure RBAC uses role assignments made of principal, role definition and scope (management group, subscription, resource group, resource), also inherited downwards; Microsoft Entra ID directory roles are a separate system, a frequent source of confusion.

Typical privilege-escalation paths come from permissions that look harmless: iam:PassRole lets a user attach a powerful role to compute they control, iam:CreatePolicyVersion lets them rewrite their own policy, and write access to a function's code inherits the function's role. Trust policies are another weak point, for example an OIDC federation for CI pipelines that omits a condition on the token's sub claim and therefore trusts every repository on the platform, or a third-party role without sts:ExternalId, which opens the confused-deputy problem. Credentials stolen from the instance metadata service via SSRF are a classic route to abusing an over-permissive role.

In practice, least privilege is approached iteratively: start from provider-managed roles, then narrow using policies generated from access logs (AWS IAM Access Analyzer, Google Cloud's role recommendations), replace long-lived access keys with short-lived credentials from STS or workload identity federation, and review with CIEM tools that compute effective permissions across all layers. The CIS Foundations Benchmarks for each provider contain concrete IAM checks such as MFA on the root account and no root access keys. Cloud IAM should be distinguished from the workforce identity provider (Entra ID, Okta and similar): the IdP authenticates people, usually federated in via SAML 2.0 or OpenID Connect, while cloud IAM authorises calls against the provider's API.