Disable `ProcessResourceProvider` by default

[inssein]

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

By default, auto instrumentation ships process.command_args, which is very dangerous as a lot of java services pass in secrets via command line arguments (see example in additional context).

Describe the solution you'd like

Can we disable this by default? I see there was some agreement to do this in open-telemetry/opentelemetry-java#3240, but the answer in open-telemetry/opentelemetry-java#4231 doesn't quite do that.

Describe alternatives you've considered

In the interim, we are testing setting OTEL_JAVA_DISABLED_RESOURCE_PROVIDERS to io.opentelemetry.instrumentation.resources.ProcessResourceProvider for all of our java apps.

Additional context

java \
  -Dkeycloak.clientSecret="${KEYCLOAK_SECRET:-test}" \
  -jar app.jar

[inssein]

Sorry, looks like the issue got auto closed when we merged an internal PR that added the workaround mentioned in alternatives.

[trask]

I would support either not capturing the command line by default, or at least scrubbing system property values, e.g. -Dkey=****.

@jack-berg @jkwatson wdyt?

[laurit]

https://opentelemetry.io/docs/specs/semconv/resource/process/ states that process.command, process.command_args and process.command_line are required.

[jack-berg]

The resolution was to:

Every ResourceProvider should have a "name", akin to the names for exporters, samplers, etc.
You then do one of 3 things:
don't specify anything extra, get all the ResourceProviders
-Dotel.java.disabled.resource.providers=process,os to exclude the "process" and "os" named ResourceProviders
-Dotel.java.enabled.resource.providers=process,os to only include the "process" and "os" named ResourceProviders

This is the behavior today.

Maybe the answer is to make it easier to discover which resource providers are available and how to opt-in or opt-out of them? We could extend the java resources doc page to include info on this, and include a table of all the resource providers, and the FQCN needed to disable them with OTEL_JAVA_DISABLED_RESOURCE_PROVIDERS.

I'm also not opposed to some suggestions around some sort of scrubbing by default.

[inssein]

My main concern here is that we should have safe defaults, and to be fair, I don't know how big of a problem this is today.

For whatever reason, majority of the java services we have today at my current workplace passes in secrets via system properties. All of our services by default would be leaking our secrets to our telemetry provider.

In the past, java services I have worked on have either gotten a configuration file with secrets or more often used environment variables, where this is not an issue.

How common is it to pass secrets via command line args, and if it's common, we need to either scrub or make it opt-in.

Edit: Is there an easy way to make only the args opt-in, and not the whole resource provider?

[jack-berg]

How common is it to pass secrets via command line args, and if it's common, we need to either scrub or make it opt-in.

I'd say common enough that we should do something safe by default. I'm in favor of scrubbing, since Lauri points out that these are currently required. I do think we should open an issue in semantic-conventions to revise either revise the conditions of "conditionally required" to give an out for languages like java where including secrets is common, or maybe even reduce the requirement level to recommended or opt-in. Can you open an issue?

[breedx-splk]

Ugh, I think it's quite unfortunate that we're considering scrubbing (changing/masking) commandline arguments because some folks (still?) pass secrets that way. It's been a bad/insecure practice for a VERY long time. The commandline arguments are something I use ALL THE TIME when troubleshooting customer issues, especially when otel specific configuration is provided via system properties (eg. -Dotel.whatever=foo). If the default implementation masked arguments, I definitely would have missed a number of problem configurations in the past.

I'd much rather favor an opt-in approach here, where users who have gone out of their way to provide secrets insecurely can prevent them from being leaked to the o11y vendor by providing an additional argument. That's my $0.02.

[cmmcleod]

@breedx-splk The reason why I want to disable these attributes is non-security related: long strings, paths, and other irrelevant data (in terms of telemetry) are passed to our applications, and ends up being a non-trivial volume of data unnecessarily transmitted along side the telemetry data.