I’ve spent the last 7 years in AWS, and now I am learning GCP, so why aren’t there courses out there that teach GCP with analogies from AWS? Maybe that’s on me to create? For now, let’s take apart the differences of GCP and AWS IAM.
Start with users… leveraging AWS as baseline understanding. In AWS we, have regular IAM users, users that exist as individual principals in a particular account, where the AWS account itself performs the authN and authZ. These users are created in IAM console of AWS. In AWS we also have Federated users/ entities, which are principals’ AuthN and AuthZ is performed by external trusted entities; and a AWS Role is assumed by that Principal that aligns with the level of AuthZ. Last we have the Root account user, which is associated to the billing email address of the account, or organization(group of accounts).
This was a bit weird for me, in Google Cloud, there are a few different entities that are “users” within a GCP account.
Google Account: A Google Account, which can be a Gmail account or a Google Workspace account, can be associated with a GCP account. It represents an individual user and can be used to access GCP services.
GCP Identity: GCP provides its own identity management system called Cloud Identity. Cloud Identity allows you to create and manage users directly within GCP. These users can be associated with specific GCP projects and have permissions and roles assigned to them.
Service Account: A service account is a special type of account in GCP that represents an application or a service rather than an individual user. Service accounts are used to authenticate applications and services that need to interact with GCP resources. Service accounts are assigned roles and permissions to access specific resources.
Google Groups: Google Groups can also be considered as users within a GCP account.
That is a bit of a brain-breaker, when using AWS as my reference, hoping this helps you. The GCP concept I needed to learn was the GCP Service Account.
The GCP service account functionality sort-of aligns to an AWS IAM Role, (although GCP also has “Roles”, ugh…more on those differences in a minute).
A service account is used by a .. service! Really, an application or compute workload, (not a human!). In GCP, A service account is identified by its email address. (weird, right?)
Applications use GCP service accounts to make authorized API calls by authenticating as the service account itself. When an application authenticates as a service account, it has access to all resources that the service account has permission to access. Service account are attached to the resource running the application, (sounds a bit like an AWS role, yeah?)
Let’s talk more about the differences with GCP and AWS Roles. While both GCP and AWS roles serve the purpose of granting permissions, GCP roles are more focused on defining permissions for specific resources or services, while AWS roles are centered around trusted entities assuming roles to acquire permissions.
AWS Roles:
In AWS, roles are Trust-based: ( think trust policy.. who can assume the role) An AWS role is a way to delegate access permissions to trusted entities, such as IAM users, AWS services, or external federated users. Roles define what actions and resources can be accessed, (via the policies attached to them); and who can assume the role.
Assumption of Roles: IAM users or services can assume an AWS role to temporarily acquire the permissions associated with that role. This, of course, enables entities to access AWS resources securely without having their own long-term access keys or credentials, YAY!
Service-oriented: AWS roles are often associated with AWS services and resources, allowing services like EC2 instances, Lambda functions, or ECS tasks to assume roles and access other AWS services. Roles can also be assumed by IAM users to gain temporary permissions.
GCP Roles:
Permissions-based: In GCP, a role is a collection of permissions that determine what actions a user or service account can perform on GCP resources. GCP provides a set of predefined roles with specific permissions, (Viewer, Editor, and Owner). Custom roles can also be created to define granular permissions.
The big differentiator for GCP… There is no concept of assuming roles in GCP. GCP roles are permission-based and are assigned directly to users or service accounts.
Henson Security Tools 