Comparing IAM models of AWS and GCP

Identity and Access Management (IAM) is key capability of any public cloud. It sets the framework for defining authentication and access control policies for its users. In this post I compare IAM models of AWS and Google Cloud Platform.

AWS IAM Model:

AWS IAM has notion of identities, resources, permissions, and policies. There are three types of identities – users, groups, and roles. A resource is any AWS resource such as S3 bucket, DynamoDB table, RDS instance, etc. A permission defines who has access to a resource and what actions they can do on it under what conditions. Permissions can be associated with identities, or they can be associated with resources. A policy is a document that establishes this association.

User’s effective permissions are union of the following: permissions directly granted to the user,  permissions granted to all the groups that the user is part of, and all the resources that identify the user as a principal in their resource-based policies.

There are permissions that control who can assume a role. When a user assumes a role, user’s own permissions are temporarily masked/removed. The user only gets permissions associated with that role during the time the user is part of the role.

When an application runs on AWS (say on a EC2 instance or as a container on ECS cluster), it runs with either the effective permissions of the user whose access keys are used to deploy the application, or the role permissions corresponding to the role that the user has assumed. There is also a notion of special service role for each AWS service. This role needs to be granted to AWS service so that it can perform actions on behalf of the running application. For EC2 this role is encapsulated in the instance profile policy. This role is passed to the EC2 instances spawned for running an application.

GCP IAM Model:

GCP IAM also has notion of identities, resources, permissions, roles, and policies. Identity is one of the following: Google account, service account, Google group, G suite domain, Cloud Identity domain. In contrast to AWS, permissions cannot be directly associated with a user (i.e. a google account). Instead, permissions are always associated with roles. Users gain permissions by being added to roles. A policy establishes relationship between users and roles.

A role is a collection of permissions. There are three types of roles – primitive roles, predefined roles, and custom roles. There are three primitive roles defined in GCP: Owner, Editor, and Viewer. Predefined roles encapsulate fine-grained permissions as compared to the primitive roles and are available for each Google Cloud platform resource.

Resources in GCP are organized in a hierarchy. The top-most level is of ‘organization’. An organization can contain one or more ‘projects’. Each project can define one or more GCP resources (such as a Cloud SQL instance, or a Google App Engine app). Policies can be set at any level of resource hierarchy. Children resources inherit parent’s policies. Policies at the children cannot be restrictive than what are defined at the parent level. Effective policy of a resource is union of: policies of that resource, all the policies of the project, and all the policies of the organization.


I have given very brief overview of the two models above. You can find much more details on the linked documentation.

Between the two models, I feel GCP’s model is bit simpler to understand. First, in GCP permissions only exist on roles. In contrast, in AWS permissions can be associated with identities and resources. But it is difficult to say whether this allows AWS permission model to be more comprehensive as compared to GCP model.

Second, the notion of a role in GCP is much more closer to the definition of role in traditional Role-based access control (RBAC) models. This enables GCP to support advanced security policies such as separation-of-duties through its notion of predefined and custom roles. In contrast, AWS’s role enactment model leads to a user temporarily relinquishing its own permissions and only gaining permissions of the role. While this is in keeping with the general spirit of RBAC – that a user once admitted to a role will have only permissions associated with that role; the fact that users themselves can have permissions, but which temporarily get blocked when being in a role can come across as a surprise initially. Another ramification of this is that policies such as separation-of-duty cannot be easily defined. They need to be defined through a combination of maintaining separate accounts, and defining user, group, and resource-level policies.

Overall, both models seem to have enough power to capture most of the authentication and authorization needs of common cloud application use-cases. Of course, it will be instructive for someone to actually formally compare them.