[
https://issues.apache.org/jira/browse/KAFKA-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16324215#comment-16324215
]
Randall Hauch commented on KAFKA-5117:
--------------------------------------
So I'm a bit concerned that simply masking the passwords will not be that
advantageous. Sure, it might work if you're just managing your configuration
files locally and then using the REST API with curl and thus never really
needing to get configurations back out. But this change would likely break
every management tool that is using the API to read, modify, and post
configurations. Also, to maintain backward compatibility, we'd need to
introduce a config file that defaults to _not masking_ -- doesn't that kind of
defeat the purpose?
[KIP-208|https://cwiki.apache.org/confluence/display/KAFKA/KIP-208%3A+Add+SSL+support+to+Kafka+Connect+REST+interface]
is already trying to add SSL/TLS support to the Connect REST API, and then
adding (with a different KIP) ACLs support would mean you can control who can
and cannot use different endpoints. That is definitely one approach to
preventing exposure of passwords.
Another approach is to avoid putting passwords in the configuration file in the
first place. KAFKA-6142 proposes adding support for variables in configuration
files, and variables could be used in place of passwords to have the passwords
resolved only upon deployment via some "configuration transformer" plugin.
> 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
> Labels: needs-kip
>
> 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
(v6.4.14#64029)
