Status Update
Comments
rr...@google.com <rr...@google.com>
rr...@google.com <rr...@google.com> #2
Hello,
Thank you for opening this public issue.
A specialized team is working and evaluating this issue. Keep in mind that here you can view the status of the issue as well as ask for updates or even add additional information that you believe would be useful for the review and/or implementation.
Please take in consideration that we can't provide you with an ETA for this issue to be resolved.Once again let me thank you for helping us to improve the functionality of our products.
ka...@gmail.com <ka...@gmail.com> #3
va...@underdefense.com <va...@underdefense.com> #4
as...@bt.com <as...@bt.com> #5
Any updates on this ?
ma...@google.com <ma...@google.com>
ma...@google.com <ma...@google.com>
ma...@google.com <ma...@google.com> #6
Hello,
According to the
Please note that the Issue Tracker is primarily meant for reporting bugs and requesting new features. If you have any additional issues or concerns, please don’t hesitate to create a new thread on the
Thanks and Regards,
Mahaboob Subhani
***Google Cloud Support ***
Description
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 accountexample_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:
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 withamiteinav@google.com and guyfeldman@google.com on the issue.
They have suggested that we request this feature.