[all][meta] Make existing sensitive configuration fields opaque

[mx-psi]

Overview

As part of open-telemetry/opentelemetry-collector#6851 and with the goal of creating a system to query the Collector's configuration, the configopaque.String type alias has been added to the core Collector library to be used on fields that contain sensitive information.

To ensure that no sensitive information is leaked on existing components' configuration, we need to audit their configuration schema and change the type on sensitive fields to use configopaque.String.

This issue intends to list all components where such a change is needed.

To generate the initial list, I searched for instances of "Token", "Key", "Password" and "Secret" on any file named config.go on this repository.

How to make the change

Changing a field type is a breaking change and should be noted as such on the changelog. Codeowners of a given component can choose to make this change with or without a deprecation, depending on how many users a component has as a Go module:

• Without deprecation by just changing the type to configopaque.String and noting it as a breaking change in the changelog (see [confighttp] Change Headers field type to have opaque values opentelemetry-collector#6637 for an example)
• With deprecation by creating a temporary field and deprecating the current field (see Add configopaque package opentelemetry-collector#6470 (comment) for a more detailed step by step plan)

My expectation is that for most fields we can do this without deprecation since usage of the Go API is minimal/nonexistent.

List of subtasks

Receivers

• [receiver/aerospike] Use configopaque for password field
• [receiver/awsfirehose] Change the type of Config.AccessKey to be configopaque.String #23829
• [receiver/bigip] Use configopaque for password field
• [receiver/cloudfoundry] Change the type of Config.UAA.Password to be configopaque.String #23832
• [receiver/couchdb] Use configopaque for password field
• [receiver/elasticsearch] Use configopaque for password field
• [receiver/jmx] Use configopaque for password, keystore_password, truststore_password fields
• [receiver/mongodbatlas] Use configopaque for private_key and secret fields
• [receiver/mongodb] Use configopaque for password field
• [receiver/mysql] Use configopaque for password field
• [receiver/nsxt] Use configopaque for password field
• [receiver/podman] Use configopaque for ssh_passphrase field
• [receiver/postgresql] Use configopaque for password field
• [receiver/pulsar] Use configopaque for auth::Token::Token and auth::athenz::private_key fields
• [receiver/rabbitmq] Use configopaque for password field
• [receiver/redis] Use configopaque for password field
• [receiver/riak] Use configopaque for password field
• [receiver/saphana] Use configopaque for password field
• [receiver/snmp] Use configopaque for auth_password and privacy_password fields
• [receiver/snowflake] Use configopaque for password field
• [receiver/solace] Use configopaque for password field
• [receiver/vcenter] Use configopaque for password field

Processors

• [processor/resourcedetection] Use configopaque for consul token field #17314

Exporters

• [exporter/alibabacloudlogservice] Use configopaque for access_key_secret field
• [exporter/azuredataexplorer] Use configopaque for application_key field
• [exporter/azuremonitor] Use configopaque for instrumentation_key field
• [exporter/coralogix] Use configopaque for private_key field
• [exporter/datadog] Use configopaque for api::key field #17296
• [exporter/dynatrace] Use configopaque for api_token field #17293
• [exporter/elasticsearch] Use configopaque for api_key and password fields
• [exporter/humio] Use configopaque for traces::ingest_token field (component is deprecated)
• [exporter/influxdb] Use configopaque for token and password fields
• [exporter/instana] Use configopaque for agent_key field
• [exporter/logicmonitor] Use configopaque for apitoken::access_key fields
• [exporter/logzio] Use configopaque for account_token field
• [exporter/mezmo] Use configopaque for ingest_key field
• [exporter/pulsar] Use configopaque for auth::Token::Token and auth::athenz::private_key fields
• [exporter/sapm] Use configopaque for access_token field
• [exporter/signalfx] Use configopaque for access_token field #17294
• [exporter/splunkhec] Use configopaque for token field #17295
• [exporter/tencentcloudlogservice] Use configopaque for secret_key field

Extensions

• [extension/asapauth] Use configopaque for private_key field
• [extension/basicauth] Use configopaque for client_auth::password field
• [extension/bearertokenauth] Use configopaque for token field
• [extension/oauth2clientauth] Use configopaque for client_secret field

[mx-psi]

This issue is big, so if you want to work on it, please pick a few components at a time and list them in a comment so that others can also work on it, thanks!

[dyladan]

i'll do the dynatrace one

[atoulme]

I’ll do the splunkhec and signalfx ones. Humio is deprecated, maybe we can pass on it.

[mx-psi]

@atoulme @dyladan I created child issues for those components and assigned them to you. I also marked humio as done since it's deprecated (thanks!)

[dyladan]

Looks like dynatrace was already done by @codeboten in 62da158 #17077

[gbbr]

Did processor/resourcedetectionprocessor: #17314 / #17315

[gbbr]

Did extension/asapauthextension: #17316 / #17317

[gbbr]

Did the rest of the extensions here: #17318. I hope it's ok for them to be part of the same PR. It was becoming tedious to do them individually.

[gbbr]

Migrated all receivers in #17353

[gbbr]

...and the exporters are here: #17354.

I think that should have covered everything now.

[MovieStoreGuy]

Hey @mx-psi ,

After reviewing #17354, I am not certain that this would be considered a breaking change considering from the user's perspective nothing has changed.
From a development perspective, I don't think this is a breaking change either considering that it is possible to cast back to the original string with no impact.

Is there anything I am missing that would cause this to be a breaking change?

[mx-psi]

Is there anything I am missing that would cause this to be a breaking change?

This will not affect end-users of Collector binaries built using the Collector builder (either official or custom), but there exist programs written before changing the type that will fail to build after changing the type because of a type mismatch. This is a breaking change, and semi-official Go tooling like apidiff would identify it as such.

I agree it is not a breaking change that would cause much pain (it's Go API only, and easy to fix), which is why I argue above that it's fine to do this in one step without deprecation, but (unless this causes significant confusion), I don't see why we should not label it as breaking when it is.

[mackjmr]

All the receivers have been updated @mx-psi, I think this issue is good to close!

[mx-psi]

Thanks @mackjmr!! 🚀 🚀