Make GOOGLE_CLOUD_PROJECT property not mandatory

[gustavovnicius]

Component(s)

gcp-auth-extension

Is your feature request related to a problem? Please describe.

Currently the gcp-auth-extension has the GOOGLE_CLOUD_PROJECT as a required property (either system properties or environment variable).

That, on some setups, is an inconvenience and one needs a few workarounds to supply that property. Which, in a first glance, is also redundant, as the extension itself requires the ADC context, and in most cases the project id can be inferred from it. See ServiceOptions on google-cloud-core package for project id resolution strategies.

Having the option to provide the project as a configuration option is still useful though, for those who have setups where the reporting and quota are on different projects.

Describe the solution you'd like

The extension should infer the project from the existing context, ideally by using ServiceOptions resolution, and not have it as a required configuration property.

In case it can neither infer it, and a project id isn't provided, then it should fail (same behavior today when the option isn't provided).

Describe alternatives you've considered

No response

Additional context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[laurit]

cc @psx95

[psx95]

Hi @gustavovnicius, thanks for opening this issue and the related PR.

There was some discussion when deciding this behavior, but basically the reason why this property was made a mandatory field was because of 2 primary reasons:

1. We use google-auth-library-java to authenticate using ADC, but last I checked there was no way to extract GCP Project ID from GoogleCredentials. I had opened an issue with the library authors requesting a feature to add a method to retrieve Project IDs from OAuth2 credentials (Unfortunately, there hasn't been much activity on it, but I will follow through with this issue again).
2. Regarding the ServiceOptions solution, IIRC the OpenTelemetry Java Contrib maintainers typically prefer if there are no vendor-specific libraries marked as dependencies in the contrib artifacts since they pull a lot of indirect dependencies that increase the maintenance burden for the community. This solution would require pulling in com.google.cloud:google-cloud-core as dependency to this artifact (That being said, I will double check this with the maintainers once). cc:@laurit does this make sense ?

Could you share some more details about the inconvenience it causes with your setup ?

Also, my apologies for the delayed response!

[Harmelodic]

Howdy 👋 I'm a colleague of @gustavovnicius

I had https://github.com/googleapis/google-auth-library-java/issues/1614 with the library authors requesting a feature to add a method to retrieve Project IDs from OAuth2 credentials (Unfortunately, there hasn't been much activity on it, but I will follow through with this issue again).

Nice! Good to know that is open (if low activity)! 👌

prefer if there are no vendor-specific libraries marked as dependencies in the contrib artifacts

But... the google-auth-library-java is a vendor-specific library, and the whole opentelemetry-java-contrib project seems to exist to enable integrating with vendors, which I'm not sure how it would be possible to do cleanly without using vendor-specific libraries, as already done.

Could you share some more details about the inconvenience it causes with your setup?

Context: Java / Spring applications running in Kubernetes on GCP (GKE), mostly as Kuberntes Deployments.

We'd like to use the OpenTelemetry Java Agent with the gcp-auth-extension for zero-code instrumentation.

In order to use the extension, we'd require setting the GOOGLE_CLOUD_PROJECT environment variable on every Deployment of every application we have.

We don't really wan to do that, since it means hardcoding project IDs in Deployment manifest files, or injecting the project ID from a single ConfigMap (though that introduces a single point of failure for all Deployments) - but we'd rather just have applications self-discover the project id from their context.

This is essentially what the ServiceOptions class provides, and works in different contexts (locally running with User credentials, GKE context with a metadata server, Compute Engine with a metadata server, etc.), and this is essentially how regular Java / Spring applications already work when running in GCP.

[psx95]

Hi @Harmelodic,

The google-auth-library-java provides 4 different artifacts. The GCP auth extension in this contrib repo only relies on google-auth-library-oauth2-http that mostly contains utility functions that allow you to get ADC. This is a lightweight artifact and taking a dependency on it does not pull in too many Google-specific dependencies (except for google-auth-library-credentials, that only contains base classes and no transitive dependencies).

The ServiceOptions route require pulling in google-cloud-core which also pulls in dependencies related to Google APIs along with the OAuth2 dependencies which makes it less ideal as a dependency for an artifact hosted in this repository.

Looking at the code responsible for fetching/inferring ProjectID inside ServiceOptions, I believe much of this code could be adopted and copied directly in the gcp-auth-extension. I would strongly prefer if https://github.com/googleapis/google-auth-library-java/issues/1614 gets resolved and we can leverage the auth library to do this task.

cc: @laurit Perhaps you can shed some light regarding vendor-specific dependencies? I remember discussing with the SIG before pulling in google-auth library.

[laurit]

Perhaps you can shed some light regarding vendor-specific dependencies? I remember discussing with the SIG before pulling in google-auth library.

I don't think we have a strict policy on that.