Supporting service account key format OR user credential formats#76
Supporting service account key format OR user credential formats#76
Conversation
This PR supports parsing both formats in either the `GOOGLE_APPLICATION_CREDENTIALS` env variable or the `~/.config/gcloud/application_default_credentials.json` file.
|
@djc I need to do real world testing on this part, but is this what you're looking for as of part 1? |
This PR adds a new `ServiceAccount` format that takes credentials from `source_credentials: ServiceAccount` and then makes a request to get a service account token using those credentials. This also adds the ability to parse the token format created by `gcloud auth application-default login --impersonate-service-account <service account>`
This PR adds a new `ServiceAccount` format that takes credentials from `source_credentials: ServiceAccount` and then makes a request to get a service account token using those credentials. This also adds the ability to parse the token format created by `gcloud auth application-default login --impersonate-service-account <service account>`
This PR adds a new `ServiceAccount` format that takes credentials from `source_credentials: ServiceAccount` and then makes a request to get a service account token using those credentials. This also adds the ability to parse the token format created by `gcloud auth application-default login --impersonate-service-account <service account>`
|
Tested this PR with real world keys
|
djc
left a comment
There was a problem hiding this comment.
This is nice and focused, thanks. I propose we scale it down a little more.
src/flexible_credential_source.rs
Outdated
| pub(crate) async fn from_default_credentials() -> Result<Self, Error> { | ||
| tracing::debug!("Loading user credentials file"); | ||
| let mut home = dirs_next::home_dir().ok_or(Error::NoHomeDir)?; | ||
| home.push(Self::USER_CREDENTIALS_PATH); |
There was a problem hiding this comment.
Is it an actually expected use case that we find ApplicationCredentials in the USER_CREDENTIALS_PATH? That doesn't seem like something that makes sense.
There was a problem hiding this comment.
I agree that this isn't a typical pattern, but Google's documentation refers to both the GOOGLE_APPLICATION_CREDENTIALS and the ~/.config/gcloud/application_default_credentials.json file as types of application default credentials, so it feels reasonable that we accept both behaviors.
https://cloud.google.com/docs/authentication/application-default-credentials#order
Additionally in the go source I have been referencing, all these credential types are contained in one struct and there isn't any runtime checks to restrict usage between certain types.
There was a problem hiding this comment.
One more thing: gcloud accepts this behavior. I can run
gcloud iam service-accounts keys create ~/.config/gcloud/application_default_credentials.json --iam-account=<service act>
gcloud auth application-default print-access-token
and the service account's token will get printed.
There was a problem hiding this comment.
Okay, in that case I suggest that we do this at the top level:
- Check for the
GOOGLE_APPLICATION_CREDENTIALSenvironment variable - If that doesn't exist, check the
USER_CREDENTIALS_PATH - For both of these, deserialize and pass the results to the appropriate trait impl
- .. other options
There was a problem hiding this comment.
Are you saying to return an error (don't try other options) if USER_CREDENTIALS_PATH exists but fails to parse as a valid ServiceAccount for some reason. This is the current behavior for GOOGLE_APPLICATION_CREDENTIALS but not USER_CREDENTIALS_PATH
There was a problem hiding this comment.
I hadn't really thought about it that way, but it seems kinda reasonable to me? Or do you think the USER_CREDENTIALS_PATH could contain other things? What does the Go code do in this case?
There was a problem hiding this comment.
Hmm. The gcloud isn't open source, and the referenced go code doesn't cover that situation. I think keeping the current behavior is fine. I don't see a reason to change since we already have been using the current behavior -- I just wanted to clarify if you were expecting that.
|
This should be ready for final checks at this point |
|
This is on my list to review, but it's been busy. Hope to get to it soon. |
|
No rush. Just wanted to make sure it wasn't waiting on me. |
|
Hey there, running into this as well when trying to run a Rust binary in a Docker container that is not running on GCP and has no I don't think this PR supports impersonation via The source for processing this content can be found here: https://github.com/golang/oauth2/blob/master/google/google.go#L223 |
|
I wouldnt mind. I likely won't have time for a while to finish this |
|
Happy to review a PR for this. |
This PR supports parsing both formats in either the
GOOGLE_APPLICATION_CREDENTIALSenv variable or the~/.config/gcloud/application_default_credentials.jsonfile.This is part 1 of the PRs addressing #56
For context see
#75 (comment)