Comparing IAM Services in AWS, Azure & Google Cloud

Introduction to IAM 
IAM Management in The Big three
IAM Management Comparison Table

IAM Services or Identity and Access management is one of the most critical parts of any IT infrastructure and cloud-based services be it AWS, AZURE or Google are no exceptions to it. All three cloud providers include an IAM architecture. The IAM system is a crucial component over cloud and governs how each individual who access cloud platform will be authenticated.

All cloud services providers be it AWS, Azure or Google cloud use some identity confederation service to connect to any existing IAM system in the organization. It could be Microsoft Active directory with ADFS or a hosted solution such as Okta. 

Today we look more in detail about IAM architecture in AWS , Azure and Google cloud, learn about IAM concept, components of IAM and how IAM management works over cloud specific to AWS, Azure and Google cloud and so on.

Introduction to IAM Services

IAM is based on the principle of ‘Least Privileges’ in information security which means that any user for a given system or resource should have been granted a minimum number of permissions and access required to perform his /her assigned role based on the business need. In the context of cloud this principle applies to any cloud resource such as storage objects, compute nodes, databases, logging dashboards which contain sensitive information pertaining to cloud tenants.

Management of separate access and authorization controls for each service or resource could be a nightmare for large deployments but with cloud unified centralized service for IAM offers a managed solution for managing access and authorizations over cloud infrastructure seamlessly.  

IAM Services Management in AWS, Azure & Google Cloud – The Big three 

IAM services are offered as foundation services and free of cost except in the case of Azure cloud where it is Active directory IAM offering with license or subscription to a separate product.

Google cloud depends on Google groups and Google account infrastructure for user management.

AWS on the other hand is self-contained within the AWS account, Azure depends on Active directory and treats users as active directory objects and enforce limits on object count. 

IAM is all about managing user access and authorization and hence all three cloud providers give capability of Role based access control (RBAC) with some minor variations. ‘Roles’ are predefined groups of access and authorization policies which define what resources users have access or not. 

Logical organization describes organizational construct around which limits and quotas will be built. In AWS quotas and limits are defined within a single account. Access and authorization policies apply only to resources and services within the specific account unless defined at cross account level roles. 

In Google cloud organizations are defined as a logical boundary and referred commonly as Project so customers can deploy all their google cloud resources under a single project or create separate projects to organize resources into logical groups and IAM can be defined for each project then.

Within Azure, the Active directory organization issues access and authorization to users. 

Users / groups defined in Google cloud with individual Google accounts but for non-interactive, credential access, Google cloud require creation of a separate service account. AWS ties users to specific AWS accounts and usually a single account is bound at account level. In Azure, Active directory is used for identity management. 

Groups are offered to allow logical and organizational policy application and users can be added / removed from groups. 

Roles are a powerful component of any IAM solution, when a user account assumes a role with that comes all the access and authorization policies tagged to that role. In AWS IAM roles are the primary way for identity mechanisms. IAM policies referred to as trust principles in AWS are used to control which principals (Could be a user or a service) are allowed to assume roles. Interactive IAM users can assume roles to carry out functions required. 

Google cloud offers roles like ‘owner’, ‘Editor’, ‘Viewer’ with their IMA service. 

Azure roles are more similar to Google cloud and it provides both pre-defined and custom roles. Built in roles come with predefined policies.

Policy configuration is defined using JSON language by all three cloud providers. In AWS user policy size cannot exceed 2048-character limit, and role policy size can’t exceed 10240 characters and group policy size can’t go beyond 5120 characters 

Google Cloud does not permit true custom policies, a list of predefined policies bound to identities (user, groups and service accounts).

Azure has a fixed limit on role assignments but no listed limit for policy size. Azure does not consider policy documents as separate resources from role identifiers; they are defined directly inline with a role, and called ‘role definition’ and roles are directly assigned to a user, group or a service principal. Polices have four hierarchical levels in Azure namely : Management group, subscription, Resource group and resource. 

IAM Services Comparison: AWS, Azure and Google Cloud

Below table summarizes the differences between the three:

FunctionAWS IAMGoogle IAMAzure IAM
User / GroupsIndividual users’ creation and add users to groups. Users do not require email id and are authorized to access various AWS resources  Create members but they must have Google account first Google email addresses added to Google groupActive directory is used for individual users and groups creation and management. (Each resource, service, user, group is an object)
PolicyPolicy is attached to a user / groupPolicy is attached to a resourcePolicy is attached to a resource
Custom PolicyCustom policy can be defined using JSON languageCustom policy can be created only from existing list permissionsCustom policy can be defined using JSON language
Policy versionPolicy versioning supportedNot supportedPolicy versioning supported
Programmatic accessAccess is enabled by attaching an IAM role to an instance, through AWS CLIIAM service account is required for programmatic accessPerform using Azure PowerShell or Azure CLI
EnvironmentsDifferent accounts can be created and linked using cross account accessCreate projects where resources of projects can be isolated from other projects in same accountManaged at Active directory and ADFS
APIsAWS provides SDK to connect to IAM APIProvides URI where you can send requests of HTTP to manage IAM servicePerform using REST API
Role stagesNo role launch stage available in AWSDifferent stages are provided to create roles such as Alpha, Beta and general availabilityAzure RBAC has over 120 built-in roles or you can create your own custom roles
Comparison by: cloudwithease.com

Download the comparison table: AWS vs AZURE vs Google cloud IAM services

Leave a Comment

four × five =

Select your currency
USD United States (US) dollar