Threat scenarios associated with abuse of iam.serviceAccountUser role

[Aleksei Feltin]

SCC OVER_PRIVILEGED_SERVICE_ACCOUNT_USER finding description contains following:

 > description: Granting the iam.serviceAccountUser or iam.serviceAccountTokenCreator role to a user for a project, a folder, or an organization gives the user access to all existing and future service accounts below it. This can result in unintended escalation of privileges. It is recommended to assign these roles to a user for a specific service account, rather than at a project level or above. 

Whilst it's clear to me the implications of iam.serviceAccountTokenCreator, I am struggling to fully understand threat scenarios related to iam.serviceAccountUser role, as it doesn't allow direct impersonation. 

https://cloud.google.com/iam/docs/service-accounts#service_account_permissions doesn't give detailed explanation, but states: "Granting the Service Account User role to a user for a project gives the user access to all service accounts in the project, including service accounts that might be created in the future." 

I am trying to understand as what are the concrete threat scenarios involving the abuse of "iam.serviceAccountUser" role. 

[Leonardo Belloc Mendiola]

An example of a threat scenario is when users can impersonate a service account that is more privileged than the user themselves, so, if a user gets the Service Account User role, they can use it to indirectly access all the resources to which the service account has access and can act as the service account to perform any tasks using its granted roles and permissions. In this link, you can see an example. Also, I'm adding this link with the best practices for securing service accounts.

[Aleksei Feltin]

Thanks Leonardo,

I understand that in order to abuse it in the privesc scenario there is also a required condition for the principal who does indirect impersonation to be able to access/create resources? Given serviceAccountUser is so ubiquitous in the GCP due to requirement of iam.serviceAccounts.actAs to access resources, I am struggling to understand what the best way is to manage it, as having it controlled at the service account IAM policy binding level can quickly become a nightmare to manage. 

--
© 2018 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043
 
Email preferences: You received this email because you signed up for the Google Compute Engine Discussion Google Group (gce-dis...@googlegroups.com) to participate in discussions with other members of the Google Compute Engine community and the Google Compute Engine Team.
---
You received this message because you are subscribed to the Google Groups "gce-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gce-discussio...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gce-discussion/f93595fe-e5e0-4047-885c-f8e03b267324n%40googlegroups.com.

[Leonardo Belloc Mendiola]

The Service account by default could have access at project level, giving access to all the resources in the project. It could lead to over-granting privileges, so it’s a best practice to avoid this behavior by not granting access to project level or folder level service accounts; instead, assign the ``iam.serviceAccountUser`` to individually manage access for each service account.

You can execute this command to get a list  to help you audit how many service accounts you have in your project.

``gcloud iam service-accounts list``