All instrumentation will have access to this. The original design of ConfigProvider intentionally limited the scope to the .instrumentation/development node, so as to avoid the questions about whether its appropriate / safe for instrumentation to have access to the SDK config model, including any secrets that may be present on the exporter nodes.

If we want to broaden scope, we need to have that conversation since its very reasonable that .distribution node will have the types of secrets that are in the SDK config model.

On a related note, why is this necessary?

The declarative config has separate parse and create methods that allow a distribution to access the .distribution node. For example in java:

OpenTelemetryConfigurationModel model = parse(new File(System.getEnv("OTEL_EXPERIMENTAL_CONFIG_FILE")));
DistributionModel distribution = model.getDistribution();
OpenTelemetrySdk sdk = create(model);

If there's not a strong need for this, the safe answer is to continue the status quo and not grant instrumentation access to more config than they need.

I'm sorry for the delayed response—I was on vacation.

ConfigProvider exposes instrumentation configuration in a clear and consistent way for all languages. I wanted the distribution configuration to be exposed consistently among languages as well. I believe this would be very beneficial, which is why this PR was created.

Regarding the recommended alternative approach, I see some issues with it:

1. It does not really improve security over the ConfigProvider extension. Extracting secrets from the declarative config file is still possible when calling the parse method, right? At the same time, it complicates life for honest developers.
2. The Java example above is problematic for Otel Java Agent-based distributions that need distribution configuration settings in AgentListeners. The SDK is configured from AgentInstaller without any extension hooks that could be used, so the config file would have to be parsed again in each listener to extract DistributionModel. Of course, we could create a dedicated AgentListener that parses the config and stores it in some static variable, but in my opinion, that starts to get tricky.
3. It will lead to inconsistent implementations among languages.

Ad 2 - instead of dedicated AgentListener we could use custom DeclarativeConfigurationCustomizerProvider that takes DistributionModel from OpenTelemetryConfigurationModel and then stores it in some static field, so it can be used later on. I still think that ConfigProvider solution is better in terms of clarity and standardization.

@robsunday I have implemented exactly what you suggested - and only saw your comment now.

My takeaway was also that it starts to get tricky with statics - see open-telemetry/opentelemetry-java-instrumentation#15822

the link points to the .instrumentation node