In GCP, there are three types of Roles that are there -
Basic
Pre-defined
Custom
Talking about the three roles in depth, the issue arises when the users use Basic or Pre-defined Roles, as they don't necessarily follow the principle of least privilege.
Where the over-permissions are given to a specific principal or resource, it becomes a problem.
Attackers View
There is not a certain attacker's view for this as it contains lots of scenario. For example a few scenarios are mentioned -
If a person needs to view just the buckets in a GCP project, Viewer role to that person might give them the access to other services data as well.
If Compute VMs are granted roles like Editor, from that resource, an attacker can perform write actions on services that they should not have access to.
If a user role contains iam.roles.update permission, then the user will be able to update the role associated with the user to gain additional privilege.
If an user has the access to generate Service Account access token - iam.serviceAccounts.getAccessToken, then the user will be able to get additional privilege associated with the Service Account.
If you're familiar with AWS IAM, the iam.serviceAccounts.actAs permission is nearly identical to the iam:PassRole permission. This means that in order for the call to succeed, you must "actAs" the Service Account as part of the resource creation process.
Defenders View
Periodic and thorough audit of the IAM Roles and Principles associated.
Run audit tools like prowler, to understand the current state of IAM and get any high privileges associated with users.
If any higher privilege permission is required for any user, the turn on the monitoring for that users' action in the organization using IAM audit logging.
Overly Permissive Permissions in GCP IAM
In GCP, there are three types of Roles that are there -
Talking about the three roles in depth, the issue arises when the users use Basic or Pre-defined Roles, as they don't necessarily follow the principle of least privilege.
Where the over-permissions are given to a specific principal or resource, it becomes a problem.
Attackers View
There is not a certain attacker's view for this as it contains lots of scenario. For example a few scenarios are mentioned -
iam.roles.update
permission, then the user will be able to update the role associated with the user to gain additional privilege.iam.serviceAccounts.getAccessToken
, then the user will be able to get additional privilege associated with the Service Account.iam.serviceAccounts.actAs
permission is nearly identical to theiam:PassRole
permission. This means that in order for the call to succeed, you must "actAs" the Service Account as part of the resource creation process.Defenders View
Tools
References