Supporting impersonated service count (builds on #76)

[msdrigg]

This PR adds service account impersonation. It uses a generic Box<dyn ServiceAccount> to get the source token and then uses that token to refresh the impersonated account from the service_account_impersonation_url.

[msdrigg]

The only weirdness about this PR is that I put the deserialization for ImpersonatedServiceAccount inside the flexible_credential_source file. I did this because in theory the source credentials could be anything (the referenced go sdk source didn't discriminate between what the source credentials were).

If there is a cleaner approach to this, please let me know.

[msdrigg]

Tested this PR with real world keys

• Tested with GOOGLE_APPLICATION_CREDENTIALS and ~/.config/gcloud/application_default_credentials.json and verified the new tagged enum is used in both cases
• Tested with service account key, user creds, and an impersonated service account and verified that I can make API calls

[danvratil]

Hi @djc, @msdrigg - we are really interested in service account impersonation (we use bigtable-rs that uses this crate under the hood). What is the current status of this PR? If there's any more work needed, I'd be happy to help.

[msdrigg]

This PR worked at the time I tested it, but I have not tested it in 2 years as you can see and now there are merge conflicts. The work that needs to be done is:

0. Get by-in from djc
1. Resolve any merge conflicts
2. Retest with real keys

[djc]

There's quite a bit of code here and it's not obvious to me why we need a separate FlexibleCredentialSource enum layer at all. Also note that at this point I'm a volunteer maintainer -- if your team depends on this project, please consider sponsoring my work.

[msdrigg]

So there is definitely some code here that can be trimmed down, but you still need some kind of flexible deserialization to cover these variables:

1. Reading GOOGLE_APPLICATION_CREDENTIALS file could contain service account or impersonated service account (different deserialization)
2. The source_credentials field on ImpersonatedServiceAccountCredentials can either be another service account or a user account.

So you basically do need something like FlexibleCredentialSource to handle this tagged enum deserialization.

I think to make this less recursive and potentially more readable, you could pull out something like this into types.rs

#[derive(Deserialize, Debug)]
struct ImpersonatedServiceAccountCredentials {Expand commentComment on line R112Code has comments. Press enter to view.
    service_account_impersonation_url: String,
    source_credentials: ServiceAccountOrUserAccount,
    delegates: Vec<String>,
}

enum ServiceAccountOrUserAccount {
    // ... tagged deserialization of service account or user account
}

// Actually deserialize this for your credential type
pub(crate) enum ServiceAccountOrImpersonatedServiceAccount {
    // ... tagged deserialization of service account or impersonated service account
}

In my PR, I combined both of these situations into a single recursive FlexibleCredentialSource, but I get that is kind of a big change that is harder to review for correctness.

[msdrigg]

I actually might could do this change to my PR and re-push it if you think it would be a welcome change djc

[djc]

You added a bunch of code, seemingly duplicating a bunch of logic, which I'm not excited about. I'd be open to reviewing the very minimal changes I could facilitate to enable you to build this downstream, and then we can review whether it makes sense to support it as part of this project (which I think might make sense, but not in its current form).

[msdrigg]

What changes would you be supportive of to make this work downstream? I am still interested in making this happen but I am not sure what you mean.