IAM Basics: Users, Roles, and Policies Across Cloud Providers
How identities, groups, policies, and scopes fit together in AWS IAM, Google Cloud IAM, Azure RBAC, Oracle Cloud compartments, and IBM Cloud access groups, with patterns that work on every provider.
Identity and access management is the part of a cloud account that decides who can do what to which resource. Every provider implements it with the same four ideas, an identity, a grouping of identities, a set of permissions, and a scope where those permissions apply, but each one names the pieces differently and attaches them in a different order. This guide lays out the model, then shows how it looks on AWS, Google Cloud, Azure, Oracle Cloud Infrastructure, and IBM Cloud so that you can read any provider’s console without relearning the concepts.
The four building blocks
An identity (or principal) is anything that can authenticate: a person, an application, or a resource such as a virtual machine. A group collects identities so that permissions can be granted once and inherited by every member. A policy or role is the list of allowed actions, written either as a document (AWS, OCI) or as a named bundle of permissions (Google Cloud, Azure, IBM Cloud). A scope is the container the grant applies to: an account, an organization, a project, a subscription, a resource group, a compartment, or a single resource.
The design question in every provider is the same: how do you connect a policy to an identity at a scope? Some providers attach policies to identities, some attach identities to roles at a scope, and some write the scope into the policy text itself. Knowing which model a provider uses tells you where to look when a permission is missing.
AWS IAM: policies attached to identities and roles
AWS IAM has users, groups, and roles inside one account. Permissions are JSON policy documents with Effect, Action, Resource, and optional Condition elements. Identity based policies attach to a user, group, or role; resource based policies attach to a resource such as an S3 bucket or KMS key and name the principals allowed to use it. A request is allowed only if some policy allows it and no policy explicitly denies it.
Roles are the central concept. A role has no long term credentials. Instead, a principal assumes it through AWS STS and receives temporary keys. EC2 instance profiles, Lambda execution roles, cross account access, and IAM Identity Center permission sets are all roles under the hood. Service control policies at the AWS Organizations level set a ceiling on what any identity in a member account can do, and permission boundaries do the same for a single user or role. Scope is expressed in the policy through resource ARNs, not through a container hierarchy.
Google Cloud IAM and Azure RBAC: roles bound at a scope
Google Cloud IAM works in the opposite direction. Permissions are grouped into roles, and a role is bound to a member (a user, group, service account, or domain) on a resource. The binding lives in the resource’s IAM policy, and it inherits down the hierarchy from organization to folder to project to individual resource. Basic roles (Owner, Editor, Viewer) are broad; predefined roles are per service; custom roles let you pick individual permissions. Service accounts are both identities and resources, so one service account can be granted the Service Account User role on another. IAM Conditions add attribute based rules such as time windows or resource name prefixes.
Azure follows the same shape with different names. Identities live in Entra ID (users, groups, service principals, managed identities). Azure RBAC role definitions such as Owner, Contributor, Reader, and dozens of service specific roles are assigned to an identity at a management group, subscription, resource group, or resource scope, and inheritance flows downward. Entra ID also has its own directory roles, such as Global Administrator, which control the directory rather than Azure resources; the two systems are separate and both need review.
Oracle Cloud and IBM Cloud: two more variations
Oracle Cloud Infrastructure IAM puts users into groups and grants access with policy statements written in a readable sentence form, for example allowing a group to manage instance-family resources in a named compartment. Compartments are the scope. They are logical containers inside a tenancy, can be nested, and every resource belongs to exactly one. Verbs run from inspect through read and use to manage, and dynamic groups let compute instances or functions match a rule and act as principals. Identity Domains, the successor to the original IAM users, add federation and MFA policies. The OCI overview explains how compartments relate to the rest of the tenancy.
IBM Cloud IAM separates platform roles from service roles. Platform roles (Viewer, Operator, Editor, Administrator) control account level actions such as creating or deleting a service instance; service roles (Reader, Writer, Manager) control what you can do inside the service. Access policies attach either to a user, a service ID, or an access group, and scope is chosen when the policy is created: all resources, a resource group, a single service, or a specific instance. Service IDs with API keys are the equivalent of service accounts, and trusted profiles let compute resources or federated users assume access without a stored key. The IBM Cloud overview covers resource groups in more detail.
| Concept | AWS | Google Cloud | Azure | OCI | IBM Cloud |
|---|---|---|---|---|---|
| Human identity | IAM user or Identity Center user | Google account | Entra ID user | IAM Domain user | IBMid user |
| Machine identity | IAM role | Service account | Managed identity or service principal | Dynamic group | Service ID or trusted profile |
| Grouping | IAM group | Google Group | Entra ID group | IAM group | Access group |
| Permission unit | Policy document | Role | Role definition | Policy statement | Platform and service role |
| Scope container | Account, resource ARN | Organization, folder, project | Management group, subscription, resource group | Tenancy, compartment | Account, resource group |
Patterns that work everywhere
- Grant permissions to groups, not individuals. Adding a person to a group is auditable and reversible; hand edited per user policies drift.
- Use the provider’s machine identity mechanism (roles, service accounts, managed identities, dynamic groups, trusted profiles) instead of creating a user for an application. It removes the stored secret entirely.
- Start with predefined or built in roles at the narrowest scope. Write a custom role only when the predefined ones are clearly too wide.
- Keep the top level scope nearly empty. Organization, tenancy, and subscription level grants should list only the administrators, and those administrators should still sign in with MFA as described in the account security essentials guide.
- Review grants on a schedule. AWS access advisor, Google Cloud IAM Recommender, Azure access reviews, and IBM Cloud inactive identity reports all show which permissions have not been used recently.
- Treat every API key as a credential to rotate, as covered in API keys and secrets management.
Where to go next
IAM setup is the first job on any new account. The marketplace lists AWS accounts across vCPU tiers, credit tiers, and Bedrock enabled variants, Oracle Cloud accounts in free trial and upgraded pay-as-you-go variants, and IBM Cloud free trial accounts. On each of them, create your groups and roles before deploying the first resource.
To see where IAM sits in the wider account structure, read What Is a Cloud Account?, then continue with the security series in the Cloud Library.