You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The concrete use case is an application that is running in a production environment within GCP. In that environment, via the metadata server, the application can obtain access tokens for a caller service account (using impersonation terminology from Google's documentation). But, in this use case, the application must perform requests to the Google Cloud
Storage API while impersonating another, privilege-bearing, service account.
This can be achieved by:
Obtaining an access token for the caller SA from the metadata server.
Using that access token for the caller SA to obtain another access token impersonating the privilege-bearing SA. For this to work, the caller SA must have roles/iam.serviceAccountTokenCreator on the privilege-bearing SA.
Finally use the privilege-bearing access token to perform requests to the Google Cloud API.
Now, it is my understanding that this use case is not supported by the google_cloud_storage crate yet. But some of the building blocks are already there, like ImpersonateTokenSource. So I believe there is a good chance for this to be implementable as a new constructor in ClientConfig, which could receive the privilege-bearing SA as parameter and wire together an appropriate token source provider. That would at least fit my current needs. Heads up: I plan on trying this out and opening a PR.
Note that there is another issue still open (#99) that also relates to impersonation. Although that one is about the Application Default Credentials (ADC) impersonation method instead.
Let me know if this doesn't make sense or if you have any remarks. Thanks.
The text was updated successfully, but these errors were encountered:
This is already implemented if you have the impersonated ADC, although somewhat in a hacky way.
It should work when provided tokens and ID by hands.
Following pseudocode does it:
I'm interested in using service account impersonation when accessing the Google Cloud Storage API. Specifically, what I need is support for the short-lived credentials impersonation method.
The concrete use case is an application that is running in a production environment within GCP. In that environment, via the metadata server, the application can obtain access tokens for a caller service account (using impersonation terminology from Google's documentation). But, in this use case, the application must perform requests to the Google Cloud
Storage API while impersonating another, privilege-bearing, service account.
This can be achieved by:
roles/iam.serviceAccountTokenCreator
on the privilege-bearing SA.Now, it is my understanding that this use case is not supported by the
google_cloud_storage
crate yet. But some of the building blocks are already there, likeImpersonateTokenSource
. So I believe there is a good chance for this to be implementable as a new constructor inClientConfig
, which could receive the privilege-bearing SA as parameter and wire together an appropriate token source provider. That would at least fit my current needs. Heads up: I plan on trying this out and opening a PR.Note that there is another issue still open (#99) that also relates to impersonation. Although that one is about the Application Default Credentials (ADC) impersonation method instead.
Let me know if this doesn't make sense or if you have any remarks. Thanks.
The text was updated successfully, but these errors were encountered: