Cybersecurity glossary
What is Cloud IAM?
Learn what Cloud IAM is, how cloud identity policies grant access to APIs and resources, and how to design roles that limit blast radius without blocking operations.
Definition
Cloud IAM is the identity and authorization control plane of a public cloud: principals (users, groups, roles, and workloads) are authenticated, then evaluated against identity-based and resource-based policies that decide which APIs and data they may use.
Why Cloud IAM matters
Public cloud APIs are powerful by design. Anyone who can create keys, attach policies, or assume a role can often reach data, change networks, or mint more identities. Cloud IAM is the control that turns that power into scoped, auditable access—or, when it is wrong, into a one-hop path from a leaked token to an entire account.
Unlike a single application login, Cloud IAM sits in front of every service: object storage, databases, functions, Kubernetes nodes, billing, and the IAM API itself. A sloppy * on one role therefore expands the attack surface of the whole environment.
How a Cloud IAM decision is made
A principal authenticates
A person federates from an IdP, or a workload presents a role, instance profile, or short-lived token.
The request names an action and resource
The caller asks to invoke a specific API on a specific object, such as reading a bucket object or describing a cluster.
Identity and resource policies are evaluated
Allow and deny statements, conditions, permission boundaries, and SCPs or org policies combine into one decision.
Conditions narrow the grant
Source IP, VPC endpoint, MFA, encryption context, and tag matching can restrict an otherwise valid permission.
The API is allowed or denied
A deny anywhere typically wins. Allowed calls should still be logged for later investigation.
Building blocks you will see in every cloud
Principals
Humans, groups, service accounts, roles, and federated workloads that can be named in policies.
Policies
JSON or CEL documents that list actions, resources, effects, and conditions.
Roles and bindings
Reusable permission sets attached to principals, often assumable rather than permanently owned.
Guardrails
Organization policies, permission boundaries, and service control policies that cap what even admins can grant.
Cloud IAM patterns compared
| Pattern | Use when | Main risk |
|---|---|---|
| Long-lived user access keys | Legacy tools that cannot assume roles | Keys leak into git, images, and laptops and rarely expire |
| Assumable roles with short tokens | Humans and jobs that can federate or use STS-style APIs | Trust policies that let the wrong account or service assume the role |
| Workload identity / IRSA / WIF | Pods, functions, and CI talking to cloud APIs | Overbroad role bindings on a service account or identity pool |
| Resource-based cross-account policy | Sharing a bucket, queue, or image with another account | Principal=* or missing conditions that make the resource public |
| Admin / Owner standing grants | Break-glass only | Any compromise of that identity becomes full-account takeover |
Cloud IAM hardening checklist
- Federate humans from a central IdP; do not create standing cloud users with console passwords and access keys.
- Replace access keys with roles, instance profiles, or workload identity and short-lived credentials.
- Write policies with explicit actions and resource ARNs; treat Action:* and Resource:* as defects.
- Separate deploy, runtime, and break-glass roles so an application identity cannot rewrite IAM.
- Use organization guardrails to block public access, root usage, and dangerous IAM mutations.
- Require MFA or hardware-backed assertions for privileged assume-role and console paths.
- Log IAM and management-plane APIs, and alert on policy changes, new keys, and privilege grants.
- Review unused permissions and roles on a schedule; shrink or delete what nothing has called.
The practical takeaway
Cloud IAM is the authorization engine of the public cloud. It maps identities to API actions on named resources, with conditions and org-level guardrails as the real safety net.
Treat every policy as production code: least privilege, no standing admin, no long-lived keys, and continuous review. A well-scoped role contains an incident. A wildcard role is the incident.
Related security terms
Identity and Access Management (IAM)
The broader identity lifecycle that Cloud IAM implements for cloud APIs and resources.
Least Privilege
The design rule Cloud IAM policies should encode: minimum permission for minimum time.
Workload Identity
How applications authenticate to Cloud IAM without long-lived access keys.
Privilege Escalation
A common outcome of overly broad IAM roles, wildcards, and pass-role mistakes.
Cloud Misconfiguration
Unsafe IAM statements are one of the highest-impact classes of cloud misconfiguration.
Frequently asked questions
What is Cloud IAM in simple terms?
It is the cloud provider’s rulebook for who can call which APIs on which resources. Users, roles, and workloads present an identity; policies decide allow or deny.
How is Cloud IAM different from enterprise IAM?
Enterprise IAM covers joiner-mover-leaver, SSO, and application access. Cloud IAM is the hyperscaler’s authorization engine for compute, storage, networking, and APIs—often federated from the enterprise IdP.
What is an IAM role versus an IAM user?
A user is a long-lived human or service identity. A role is an assumable identity that issues temporary credentials. Prefer roles and federation over standing user keys.
What is an identity-based policy versus a resource-based policy?
Identity-based policies attach to the principal. Resource-based policies attach to the resource (bucket, queue, function) and can grant cross-account access. Both must be considered together.
Why do wildcard IAM permissions cause incidents?
Wildcards such as Action:* or Resource:* grant far more than the task needs. A stolen role then becomes a platform-wide key instead of a scoped credential.
Should applications use access keys?
Avoid long-lived access keys. Use workload identity, instance or pod roles, and short-lived tokens so compromise expires quickly and keys never sit in images or CI variables.
How do teams review Cloud IAM safely?
Inventory principals, simulate policy evaluation, flag unused and overprivileged roles, require reviews for admin and pass-role grants, and log every authorization-relevant API call.
References
Explore authoritative guidance and frameworks related to cloud iam.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.