Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support service account impersonation short-lived credentials with GCS #288

Open
manuteleco opened this issue Jul 20, 2024 · 1 comment
Open

Comments

@manuteleco
Copy link

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:

  1. Obtaining an access token for the caller SA from the metadata server.
  2. 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.
  3. 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.

@bioothod
Copy link

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:

    let file = std::fs::File::open(cred_file)?;
    let reader = std::io::BufReader::new(file);
    let js: serde_json::Value = serde_json::from_reader(reader)?;

    let sa_url = &js["service_account_impersonation_url"];
    if !sa_url.is_string() { return Err(); }

    let cred = &js["source_credentials"];
    if !cred.is_object() { return Err(); }

    // hack zone
    let mut cred = CredentialsFile::new_from_str(&cred.to_string()).await?;
    cred.service_account_impersonation_url = Some(sa_url.to_string());

    let config = ClientConfig::default().with_credentials(cred).await?;
    let client = Client::new(config);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants