IssueTracker

What you would like to accomplish:

Confused deputy attacks can happen in GCP when service account impersonation is used.

To establish unique trust that can’t be exploited by a confused deputy attack, client-vendor trust should include a non-public (and at the very least hard-to-guess) component.

The attack would go as follows: Before the attack, ExampleCompany registers with ExampleVendor. To enable ExampleVendor to act in your production environment, you create the service account example_vendor@client_prod.iam.gserviceaccount.com, allowing example_vendor_prod@example_vendor_prod.iam.gserviceaccount.com to impersonate it. An attacker sets up a new profile with the ExampleVendor and inputs example_vendor@client_prod.iam.gserviceaccount.com as the service account that ExampleVendor can impersonate. The attacker can now log into their profile with the ExampleVendor.

How this might work:

We would suggest a similar solution to the AWS ExternalId solution.(https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)

The customer registers with ExampleVendor. ExampleVendor asks the customer to grant permissions to impersonate a service account with an external ID condition provided by the vendor. When ExampleVendor uses any of the service account impersonation methods (https://cloud.google.com/iam/docs/reference/credentials/rest/v1/projects.serviceAccounts), GCP checks that the external ID of the connection request is identical to that set by the customer in its service account.

If applicable, reasons why alternative solutions are not sufficient:

Currently, most third-party vendors use permanent service account keys to access customer environments, creating credential leakage risk. Workarounds are possible. A vendor can do one of the following:

• Create a unique service account per customer
• Request a specific vendor-generated service-account name in the customer environment
• Label the project with a unique identifier and check it while impersonating

All of these solutions: Are insecure by default (insecure unless the vendor takes active steps) Create workflow inconvenience Rely on vendor and customer behavior to be effective

Other information:

We have consulted with amiteinav@google.com and guyfeldman@google.com on the issue. They have suggested that we request this feature.