-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[all][meta] Make existing sensitive configuration fields opaque #17273
Comments
This comment was marked as resolved.
This comment was marked as resolved.
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! |
i'll do the dynatrace one |
I’ll do the splunkhec and signalfx ones. Humio is deprecated, maybe we can pass on it. |
Looks like dynatrace was already done by @codeboten in 62da158 #17077 |
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. |
Migrated all receivers in #17353 |
...and the exporters are here: #17354. I think that should have covered everything now. |
…String This change migrates the remaining exporters from open-telemetry#17273 to use configopaque.String: - [x] [exporter/alibabacloudlogservice] Use configopaque for access_key_secret field - [x] [exporter/azuredataexplorer] Use configopaque for application_key field - [x] [exporter/azuremonitor] Use configopaque for instrumentation_key field - [x] [exporter/coralogix] Use configopaque for private_key field - [x] [exporter/elasticsearch] Use configopaque for api_key and password fields - [x] [exporter/influxdb] Use configopaque for token and password fields - [x] [exporter/instana] Use configopaque for agent_key field - [x] [exporter/logicmonitor] Use configopaque for apitoken::access_key fields - [x] [exporter/logzio] Use configopaque for account_token field - [x] [exporter/mezmo] Use configopaque for ingest_key field - [x] [exporter/pulsar] Use configopaque for auth::Token::Token and auth::athenz::private_key fields - [x] [exporter/sapm] Use configopaque for access_token field - [x] [exporter/tencentcloudlogservice] Use configopaque for secret_key field
This change updates sensitive information described in open-telemetry#17273 for all receivers: - [x] [receiver/aerospike] Use configopaque for password field - [x] [receiver/awsfirehose] Use configopaque for access_key field - [x] [receiver/bigip] Use configopaque for password field - [x] [receiver/cloudfoundry] Use configopaque for password field - [x] [receiver/couchdb] Use configopaque for password field - [x] [receiver/elasticsearch] Use configopaque for password field - [x] [receiver/jmx] Use configopaque for password, keystore_password, truststore_password fields - [x] [receiver/mongodbatlas] Use configopaque for private_key and secret fields - [x] [receiver/mongodb] Use configopaque for password field - [x] [receiver/mysql] Use configopaque for password field - [x] [receiver/nsxt] Use configopaque for password field - [x] [receiver/podman] Use configopaque for ssh_passphrase field - [x] [receiver/postgresql] Use configopaque for password field - [x] [receiver/pulsar] Use configopaque for auth::Token::Token and auth::athenz::private_key fields - [x] [receiver/rabbitmq] Use configopaque for password field - [x] [receiver/redis] Use configopaque for password field - [x] [receiver/riak] Use configopaque for password field - [x] [receiver/saphana] Use configopaque for password field - [x] [receiver/snmp] Use configopaque for auth_password and privacy_password fields - [x] [receiver/snowflake] Use configopaque for password field - [x] [receiver/solace] Use configopaque for password field - [x] [receiver/vcenter] Use configopaque for password field
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. 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 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. |
…String (#17354) This change migrates the remaining exporters from #17273 to use configopaque.String: - [x] [exporter/alibabacloudlogservice] Use configopaque for access_key_secret field - [x] [exporter/azuredataexplorer] Use configopaque for application_key field - [x] [exporter/azuremonitor] Use configopaque for instrumentation_key field - [x] [exporter/coralogix] Use configopaque for private_key field - [x] [exporter/elasticsearch] Use configopaque for api_key and password fields - [x] [exporter/influxdb] Use configopaque for token and password fields - [x] [exporter/instana] Use configopaque for agent_key field - [x] [exporter/logicmonitor] Use configopaque for apitoken::access_key fields - [x] [exporter/logzio] Use configopaque for account_token field - [x] [exporter/mezmo] Use configopaque for ingest_key field - [x] [exporter/pulsar] Use configopaque for auth::Token::Token and auth::athenz::private_key fields - [x] [exporter/sapm] Use configopaque for access_token field - [x] [exporter/tencentcloudlogservice] Use configopaque for secret_key field
…que.String` **Description:** Split out from: open-telemetry#17353 **Link to tracking Issue:** open-telemetry#17273
…opaque.String` **Description:** Split out from: open-telemetry#17353 **Link to tracking Issue:** open-telemetry#17273
…Password}` fields to be of `configopaque.String` **Description:** Split out from: open-telemetry#17353 **Link to tracking Issue:** open-telemetry#17273
…igopaque.String` **Description:** Split out from: open-telemetry#17353 **Link to tracking Issue:** open-telemetry#17273
… to be `configopaque.String` **Description:** Split out from: open-telemetry#17353 **Link to tracking Issue:** open-telemetry#17273
…opaque.String` **Description:** Split out from: open-telemetry#17353 **Link to tracking Issue:** open-telemetry#17273
All the receivers have been updated @mx-psi, I think this issue is good to close! |
Thanks @mackjmr!! 🚀 🚀 |
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:
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)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
Config.AccessKey
to beconfigopaque.String
#23829Config.UAA.Password
to beconfigopaque.String
#23832Processors
Exporters
[exporter/humio] Use configopaque for traces::ingest_token field(component is deprecated)Extensions
The text was updated successfully, but these errors were encountered: