AWS, Azure, and GCP: The Ultimate IAM Comparison

IAM (Identity and Access Management) is one of the most important yet complicated layers of cloud security. To add insult to injury, each major cloud provider (AWS, Azure, GCP) handles IAM differently, requiring cloud security professionals to learn different capabilities, restrictions, and terminology when managing IAM in a given environment. With infrastructure cloudification growing in depth and breadth, cloud security professionals – even if they’re not currently working in a multi-cloud environment – will want to, and should, gain proficiency in the IAM of different CSPs.

Where to begin? In this post, we provide the ultimate cloud IAM overview, comparing AWS, Azure, and GCP. After reading the blog post, you will have a foundational understanding of the IAM cloud security of the major providers. 

How Resources Are Structured in the Cloud

Cloud resources are all the tools and applications that make up a cloud computing environment. These include servers, databases, data storage components, and more. Understanding this structure is important to understand how permissions are assigned and should be managed.

Let’s look at how each cloud provider structures its cloud resources.

Resource Structure in AWS

In AWS, the main container is called an AWS account, which can be set up and used to provision resources. Enterprises usually have multiple AWS accounts. Accounts can be consolidated using AWS Organizations, an AWS cloud-native service.

The question of how many accounts should be managed by a single AWS Organizations unit is of constant debate in the infosec community. For example, some subscribe to the notion that one account is enough for all stages – such as development, staging, and production – while others prefer one account for each stage of an application. In the latter case, for example, one account would cover Application 1 for its development, staging, and production environments, and another account would cover Application 2 for its development, staging, and production environments.

“Root” is the parent container for all organizational accounts.

Resource Structure in Azure

Unlike AWS, Azure (and GCP) employ an RBAC (role-based access control) model, which relies on a more methodical structure of resources. At the primary level, Azure provides a basic resource container, the “resource group.” Each resource group container groups all the resources meant for one specific application, so they can be provisioned and de-provisioned together.

A container that can hold resource groups is a “subscription.” A container that can hold subscriptions is a “management group” (which can also hold other management groups in a nested structure). Multiple management groups consist of a “root management group.” In Azure, a subscription is also the billing unit.

The Azure structure is intended to align with the enterprise’s organizational structure.

Resource Structure in GCP

In GCP, the basic container is the “project,” which contains the resources for a single application. A “folder” is a container that can aggregate several projects. The folder consists of a nested structure all the way up in the organizational tiers. In GCP, the project is also the billing unit.

Resource Structure: AWS vs Azure vs GCP

While Azure and GCP employ an RBAC model that imitates the organizational structure, AWS provides less structure and fewer management capabilities in its resource structure. This will be important later on when setting permissions across different resource levels.

How Permissions Are Listed and Assigned in the Cloud

In the cloud, permissions are assigned through a permissions document. This document depicts which users and entities have access to which resources according to policies. Each cloud provider enables admins to manage their own permissions documents or offers permissions documents that it itself manages.

Listing Permissions in AWS

In AWS, the permissions document, named “IAM Policy,” includes the details of the permissions and the resources in the same JSON file. This means there is no decoupling of the resources that the identity is granted access to and the actions that the permissions allow the identity to perform – both are managed in one document.

Below is a very permissive AWS policy, which provides permissions to all the actions relevant to S3 and on all S3 buckets. As you can see, the resources and actions are in the same document.

Listing Permissions in Azure

Unlike AWS, in Azure (and GCP), the list of permissions is decoupled from the resources. The resources for which a permission assignment would apply are called a "scope." For example, a scope can be a resource or a container of resources, and containers of resources can comprise other containers of resources. In addition, because Azure follows RBAC permissions, it enables inheritance: if a role is at a higher scope, it has a wider set of permissions.

Below is an Azure policy – as you can see, the "role" doesn't actually contain information about where it applies because it can be used on various scopes when creating a role assignment. It does include information about where it could potentially be applied (in this case, the assignableScopes field).

Listing Permissions in GCP

GCP also separates the permissions from the resources in the document named “role.” Similar to Azure, the role document does not list resources. It is the responsibility of the cloud security engineer or IT to place this document on a resource or resource scope. By putting the files in a GCP project or folder, the permissions listed will be applicable to all resources in that location.

As for Azure, in GCP, the resources for which a permission assignment would apply is called a scope, which can be, for example, a resource or a container of resources. Because GCP follows RBAC permissions, it enables inheritance: if a role is at a higher scope, it has a wider set of permissions.

Listing Permissions: AWS vs Azure vs GCP

AWS consolidates permissions and resources in a single JSON file (called a policy). Permissions to resources are assigned to identity via a policy. This is unlike Azure and GCP, which separate the permissions set from the scope; each assignment involves attaching permissions and resources to an identity.

In addition, because Azure and GCP follow RBAC permissions, they enable inheritance. Inheritance means that if a role is at a higher scope, it has a wider set of permissions.

Access Use Cases

Two types of identities need access: users, i.e., human identities, and services, i.e., machines or applications. Let’s look at how admins in each of the major clouds can give access to each kind of identity.

User Access Management

User Access Management in AWS

In AWS, admins can create a resource named “IAM user,” an object that represents the resource, and an IAM policy that determines access capabilities. AWS also enables bundling users together in “IAM User Groups.”

However, using the “IAM users” object can become cumbersome when needing to give users access to multiple accounts, as IAM users reside in specific accounts and would therefore require cross-account access.

In AWS, the best practice is to manage users through an external identity provider (IdP). With an IdP, users are represented through a proxy identity called an “IAM role.” The IAM role allows the identity provider to delegate access to this user.

AWS has also introduced an AWS tool, AWS SSO, that enables the centralized management of identities and federation of users by identity providers. Using a “permissions set,” admins can manage and provide access to users in AWS accounts. AWS SSO can also automatically create roles and the policies that are attached to them.

User Access Management in Azure

For user management, Azure offers the Azure Active Directory (Azure AD) – the identity provider where users are managed. This includes creating new users, inviting guest users, or managing how they access applications.

Azure AD also enables managing users in groups. Users are added to groups, and groups can be nested inside each other, i.e., one group can be put inside another, which is very helpful when assigning permissions.

User Access Management in GCP

In GCP, users are managed through Google Cloud Identity or Google Workspace. Like Azure, GCP enables managing users and groups called Google Groups. In addition, GCP has additional entities that can be given permissions, including domain, service accounts, authenticated users, and all users.

One thing to note in GCP is that both “all users” and “authenticated users” groups are not specific to an instance of Google Cloud Identity or Google Workspace. Rather, they are relevant to all Google accounts and users on the internet, so they are essentially public.

Service Access Management

Now let’s talk about how access is assigned to service identities.

Service Identities in AWS

In AWS, service identities can be given access to resources by the assumption of IAM roles. For example, a Lambda in AWS may access resources by assuming an IAM role. This configuration is done by allowing the AWS Lambda service to assume the role.

Service Access Management in GCP

Similar to AWS’s IAM role, GCP enables providing access to a type of proxy identity called a “service account.” As in AWS, cloud functions (the GCP Lambda equivalent) can have a service account attached to them, and the cloud function can then use the permissions granted to that service account.

Service Access Management in Azure

Unlike AWS and GCP, Azure does not provide an object that can be assumed by other users or services. Instead, Azure provides two options for managing service access.

The first is for giving resource access to services by creating a “managed identity,” which enables granting access without needing to manage credentials. A managed identity can be system-assigned or user-assigned:

• System-assigned: Depicts a one-to-one relationship between a specific resource and other resources through a role
• User-assigned: Is created separately from the resources. It can be granted access and then attached to the resources that need to perform the job functions. As a result, multiple resources required to perform the same job functions can be attached to a single-managed identity.

The second option for providing access in Azure is by using a “service principal.” To use a service principal, the first step is to register the application. The registered application object provides credentials that enable authentication to Azure. A service principal is then created for it on its home tenant. When you are installing an app from another tenant, a service principal is created for the app in your tenant.

Providing External Access in AWS, Azure, and GCP

Organizations often need to give external access to third parties, such as to obtain support services from them.

In AWS, external access is provided through a resource-based policy. In AWS, admins manage the resources (not the identities), so providing access to an identity takes place through a resource-based policy that details the permissions and is attached to the resource.

Since creating a resource-based policy for each resource for which access is required is not scalable, admins can create an IAM role that can be assumed externally. Such a policy lists the external accounts that are provided access.

In Azure, separating the service principal from the app enables providing the application with external access to other tenants. To provide external access, a service principal is created when the app is installed in the tenant. The permissions granted to that service principal provide the application with permissions to external resources in other tenants.

In GCP, a service account is used to provide access to third parties. GCP enables providing access easily by simply creating a binding for an external identity on a service account with a role that can be impersonated.

These webinars can help you drill down further into understanding permissions analysis and IAM risk: AWS workshop, Azure workshop, and GCP workshop.

Pitfalls to Look Out For

Now that we’ve covered how permissions work let’s review some pitfalls that a cloud security expert should look out for when handling cloud IAM permissions.

1. Static Credentials

Static Credentials in AWS

AWS has a static credential: the “IAM user access key.” The access key is made up of only two strings: the access key ID and the secret access key.

It is not good practice to use this credential to give access since it can be easily impersonated or leaked. For example, a developer can accidentally add it to GitHub on a public bucket. In addition, these credentials are very hard to monitor. Despite these warnings, some admins still use the access key to give access to the CLI – to machines or even a third party. You can learn more on reducing the risk of static credentials by viewing the AWS IAM User Access Keys webinar.

Static Credentials in GCP

Similar to AWS, in GCP, the service account can have a static key pair, which is risky and can be accidentally leaked or maliciously breached.

Static Credentials in Azure

In Azure, multiple resources have static credentials, called “access keys,” that allow almost complete access to them by default. Storage accounts are one such example. Unless disabled, these access keys allow access and can be breached or leaked. Azure also allows authentication to a registered application using a "secret," which is really just a string that allows access to the application. Beware.

2. Using Provider-Managed Policies

As mentioned earlier, the cloud provider can create and manage policies – and also unilaterally change them. In addition, managed policies are usually overly excessive since they are created based on the provider’s ballpark estimation of what the role requires. Such excessive permissions are a violation of the principle of least privilege.

AWS users should especially be on the lookout for these policies since permissions in AWS also include the resources that the identity can access. There is also a tendency to use a wildcard (*.*), which makes all the resources accessible. In GCP and Azure, this tendency can become dangerous if the wildcarded permissions are added to a high-level scope or give excessive roles to a basic role, like Viewer or Editor.

3. Unwarranted Public Access

Some configurations are dangerous since they unknowingly give the public access to sensitive resources. For example, an AWS resource-based policy that gives public access and configures the principal as a star, granting access to all existing principals. This configuration makes the resource public. As mentioned before, in GCP, the identifiers “allUsers” and “allAuthenticatedUsers” also make a resource public.

Guardrails

Each cloud provider has taken steps to control access management and prevent breaches by putting guardrails in place. Let’s look at the most important ones:

AWS Guardrails

AWS uses a multi-stage, complex process when evaluating whether to give permissions. Multiple mechanisms like identity policies, resource-based policies, a permission boundary, a service control policy, a session policy, and more are reviewed during the evaluation process. These mechanisms prevent identities from having access to certain permissions even if granted access – enhancing security and helping protect specific, valuable resources.

In AWS, admins can set policies for identities or set access permissions from resources, creating a perimeter around them. This policy-setting approach makes AWS very flexible for admins and an effective guardrail.

GCP Guardrails

An effective GCP guardrail is the IAM Deny policy. This policy is a set of rules that determines what a principal is denied access to. The GCP Deny policy is applicable to organizations, folders, or projects and applies the same inheritance rules as IAM policies. The Deny policy supports some of the conditions and some of the permissions. You can use a Deny policy to, for example, prevent making resources public.

Azure Guardrails

Azure provides multiple guardrails; however, most are fairly straightforward (and not too sophisticated). Let’s look at the main ones:

• Locks - Enables setting a lock on a resource or resource group to make it Read Only or prevent deletion. Locks do not enable determining more specific configuration conditions.
• Deny Assignments - Denies actions to a user, group, or service principal, even if the role assignment provides them with access. This is a robust guardrail that enables adding multiple conditions.
• Conditional Access - A useful tool for user access management through “if-then” policies.
• Azure Policy - A tool for monitoring activity in the Azure tenant to enforce certain rules. While Azure Policy was not set up as a guardrail, you can use it as one.

Benefits of an Automated Analysis Platform

We’ve covered providing access to users and services in the cloud, but what about security? An automated analysis platform analyzes configurations and logs in your cloud environment to understand which permissions are granted to which identities and if these permissions are actually required. Such a platform is able to provide a clear overview of all the privileges in an environment to enable pinpointing excessive permissions or toxic combinations.

By analyzing these permissions continuously, IT, DevOps, and admins can ensure visibility at all times in this dynamic environment. Such a platform can also remediate these issues by providing applicable policies that help meet regulations and achieve the least privilege.

Conclusion

Cloud IAM is complex unto itself, let alone when trying to manage it securely in the environments of different cloud providers. An automated analysis platform that operates across multiple clouds can help close gaps in cloud expertise while monitoring permissions to ensure cloud security. This will help reduce the cloud security risks of IAM in a simple and insightful manner.