Identity
Who or what is making the request — a person, or a non-human identity representing an application or workload.
Cloud fundamentals
IAM Basics Across Clouds
Every provider answers the same question — who can do what, to which resource — with the same handful of building blocks under different names.
The shared building blocks
Four pieces show up in every provider's IAM model, whichever vendor's console you're looking at.
Role
A named set of permissions, designed to be assumed temporarily rather than tied permanently to one identity.
Policy
The actual grant — a statement of which actions are allowed or denied on which resources.
Resource hierarchy
Permissions are usually inherited down a tree (organization → project/account → resource), so a policy set high up can apply broadly without repeating it everywhere.
Same model, different names
The mental model transfers directly between providers — only the vocabulary and console layout change.
| Concept | AWS | Azure | GCP |
|---|---|---|---|
| Human identity | IAM User | Microsoft Entra ID account | Google Account |
| Non-human (app/workload) identity | IAM Role (assumed) | Managed Identity / Service Principal | Service Account |
| Permission grant | IAM Policy (JSON, attached to user/role/group) | RBAC Role Assignment | IAM Policy Binding |
| Grouping resources for permission scope | Account / Organization | Resource Group / Subscription / Management Group | Project / Folder / Organization |
One nuance worth remembering
GCP's resource hierarchy (Organization → Folder → Project → Resource) is the most explicit about permission inheritance flowing downward. AWS Organizations and Azure Management Groups do the same thing conceptually, but it's easier to miss since a plain AWS account or Azure subscription can exist without ever touching the org-level tooling.
Related
See IAM, IAM role, IAM policy, and service account in the Glossary. For the security principle behind role design, see least-privilege IAM in Production Security & Deployment Models.