feat: support both identity and token source for gke metadata server mode #286
Conversation
foundation/auth/src/project.rs
Outdated
| /// | ||
| /// Returns an error if neither audience nor scopes are provided, or if any technical error occurs. | ||
| pub async fn create_token_source_from_metadata_server(config: &Config<'_>,) -> Result<Box<dyn TokenSource>, error::Error> { | ||
| match config.audience { |
There was a problem hiding this comment.
In google-cloud-pubsub and others, since the audience is set when the client is generated, this application will force the idtoken.
We checked google-cloud-go and did not see any use of idtoken, so we would like to position this as an option.
pub async fn create_token_source_from_project(
project: &Project,
config: Config<'_>,
) -> Result<Box<dyn TokenSource>, error::Error> {
match project {
Project::FromFile(file) => {
if config.use_id_token {
id_token_source_from_credentials(Default::default(), file, config.audience.unwrap_or_default()).await
}else {
create_token_source_from_credentials(file, &config).await
}
},
Project::FromMetadataServer(_) => {
let ts = if config.use_id_token {
ComputeIdentitySource::new(&config.audience.unwrap_or_default())?
}else {
ComputeTokenSource::new(&config.scopes_to_string(","))?
};
let token = ts.token().await?;
Ok(Box::new(ReuseTokenSource::new(Box::new(ts), token)))
}
}
}How about the following code? This would allow the use of idtoken even when credentials are used.
There was a problem hiding this comment.
Sounds good to me.
I will update based on your feedback and test it by tomorrow.
There was a problem hiding this comment.
Tested. No issue found.
My tests covered both authentication tokens (OAuth and ID) from GKE, for in-house target services (cross project cloud run through PSC setup) as well as same project/cross project Google Cloud APIs (Vertex endpoints for example)
| @@ -68,7 +68,7 @@ pub async fn create_id_token_source( | |||
| } | |||
| } | |||
|
|
|||
| async fn id_token_source_from_credentials( | |||
| pub(crate) async fn id_token_source_from_credentials( | |||
There was a problem hiding this comment.
@yoshidan Not sure about your preference in term of visibility ?
There was a problem hiding this comment.
The scope you specified is fine.
|
Thanks! |
|
ref #287 |
Description
The changes included in this PR give us the ability to generate different token types when relying on the GKE metadata server.
In the current version, only OAuth 2.0 tokens can be generated.
What was done
In the exact same way as when using the Credential File mode, we know can:
audiencescopesThis is useful when we want to access remote services (across shared VPC, VPC, PSC, whatever) like custom services, cloud run instances that are protected with basic authentication.
How has it been tested
cloud.run.invokerrole to the service account used.