|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:
|Function||AWS IAM||Google IAM||Azure IAM|
|User / Groups||Individual 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 group||Active directory is used for individual users and groups creation and management. (Each resource, service, user, group is an object)|
|Policy||Policy is attached to a user / group||Policy is attached to a resource||Policy is attached to a resource|
|Custom Policy||Custom policy can be defined using JSON language||Custom policy can be created only from existing list permissions||Custom policy can be defined using JSON language|
|Policy version||Policy versioning supported||Not supported||Policy versioning supported|
|Programmatic access||Access is enabled by attaching an IAM role to an instance, through AWS CLI||IAM service account is required for programmatic access||Perform using Azure PowerShell or Azure CLI|
|Environments||Different accounts can be created and linked using cross account access||Create projects where resources of projects can be isolated from other projects in same account||Managed at Active directory and ADFS|
|APIs||AWS provides SDK to connect to IAM API||Provides URI where you can send requests of HTTP to manage IAM service||Perform using REST API|
|Role stages||No role launch stage available in AWS||Different stages are provided to create roles such as Alpha, Beta and general availability||Azure RBAC has over 120 built-in roles or you can create your own custom roles|
Download the comparison table: AWS vs AZURE vs Google cloud IAM services