[ https://issues.apache.org/jira/browse/KAFKA-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Randall Hauch reopened KAFKA-5117: ---------------------------------- Assignee: Randall Hauch (was: Ewen Cheslack-Postava) I'm reopening this because there appears to be a bug in the worker that incorrectly returns the externalized secrets when getting the connector config from the REST API. Instead, the REST API should return the config with the raw configuration values, including those of the form `${provider:path:key}`. [KIP-297|https://cwiki.apache.org/confluence/display/KAFKA/KIP-297%3A+Externalizing+Secrets+for+Connect+Configurations] is actually not really clear on whether the REST API will be affected, and so IMO its behavior should not have been changed by the implementation of KIP-297 and should return the connector configuration submitted via PUT and stored by the worker as before KIP-297. Only this behavior really works with tooling that edits connector configurations via GET and PUT operations. IMO, *any other behavioral changes should be determined through a new KIP.* Here are the details. Consider a standalone worker config defines a config provider (using the example `{{FileConfigProvider}}` added by KIP-297): {code} ... # Define a config provider that reads from any file config.providers=file config.providers.file.class=org.apache.kafka.common.config.provider.FileConfigProvider {code} Then, create a connector with at least one property with an externalized placeholder for its value: {code} name=my-connector ... connection.user=foobar connection.password=${file:/path/to/secret.properties:db.password} ... {code} where the `{{/path/to/secrets.properties}}` file contains: {code} ... db.password=my-secret ... {code} then Connect will use the FileConfigProvider to replace the placeholder on the `{{connection.password}}` value with the `{{db.password}}` property in the `{{/path/to/secrets.properties}}` file *before* these properties are given to the connector upon startup. In fact this works just fine. The problem is that when we perform a `{{GET}} connectors/my-connector/` we get the following: {code} { "name": "my-connector", "config": { "connector.class": "io.confluent.connect.jdbc.JdbcSourceConnector", "mode": "incrementing", "incrementing.column.name": "id", "topic.prefix": "jdbc-", "connection.password": "my-secret", "connection.user": "foobar", ... {code} Note how the `{{connection.password}}` property is `{{my-secret}}` but should instead be `{{${file:/path/to/secret.properties:db.password}}}`. > Kafka Connect REST endpoints reveal Password typed values > --------------------------------------------------------- > > Key: KAFKA-5117 > URL: https://issues.apache.org/jira/browse/KAFKA-5117 > Project: Kafka > Issue Type: Bug > Components: KafkaConnect > Affects Versions: 0.10.2.0 > Reporter: Thomas Holmes > Assignee: Randall Hauch > Priority: Major > Labels: needs-kip > Fix For: 2.0.0 > > > A Kafka Connect connector can specify ConfigDef keys as type of Password. > This type was added to prevent logging the values (instead "[hidden]" is > logged). > This change does not apply to the values returned by executing a GET on > {{connectors/\{connector-name\}}} and > {{connectors/\{connector-name\}/config}}. This creates an easily accessible > way for an attacker who has infiltrated your network to gain access to > potential secrets that should not be available. > I have started on a code change that addresses this issue by parsing the > config values through the ConfigDef for the connector and returning their > output instead (which leads to the masking of Password typed configs as > [hidden]). -- This message was sent by Atlassian JIRA (v7.6.3#76005)