[
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)
