[
https://issues.apache.org/jira/browse/KAFKA-9284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16998375#comment-16998375
]
ASF GitHub Bot commented on KAFKA-9284:
---------------------------------------
rondagostino commented on pull request #7843: (DO NOT MERGE) KAFKA-9284:
Zookeeper TLS docs and system tests
URL: https://github.com/apache/kafka/pull/7843
Initial commit, just a working system test for now, no docs.
I discovered that mutual authentication is required, so client needs
a key store in addition to a trust store. Also, client key store
password must be the same as any password associated with the key in
that key store -- if the passwords don't match (or if the key store is
not specified at all) then the client wil be unable to connect to
Zookeeper on the TLS clientSecurePort.
Specifying the required parameters (e.g. key/trust store locations and
password, etc.) currently must be done via Java system properties, and
it is possible to define system properties via "-D" flags at the command
line. This is less than desireable because command line arguments are
insecure. A better approach would be to specify them in a .properties
file and have the JVM read them from there. This might be doable by
alowing the bin/kafka-run-class.sh script to accept a pair of parameters
(e.g. -sysprops /path/to/system.properties) and invoke a wrapper class
when loading system properties from a file is requested; the wrapper
class could read and apply the system property definitions before
forwarding the invocation to the intended class. Adding actual Kafka
configs is another option, but I think that would only apply to the
brokers -- command line tools (Zookeeper security migration tool, etc.)
would still need a separate solution.
If/how client certificate authentication can work with the Zookeeper
security migration tool (which adds ACLs to lock down znodes) is an
open question and requires more investigation. For example, can SASL
authentication work on top of certificate authentication? If so then
it is perhaps an acceptable first pass to leave things as they are --
only support applying Zookeeper ACLs on the SASL identity. But if not,
or if we wish to support ACLs based on the certificate identity, then
we have to investigate how this can be done (maybe no change is needed)
and also if we can support adding ACLs multiple certificate identities.
If we can't support ading ACLs for multiple certificate identities then
we would be constrained to all brokers authenticating with the same
certificate. So there is investigation to be done here.
KIP 515 was opened to address some of the above issues but it has been
dormant for a while (and the number 515 was actually already taken by
another KIP); this KIP might need to be revived (with a new KIP number).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add documentation and system tests for TLS-encrypted Zookeeper connections
> --------------------------------------------------------------------------
>
> Key: KAFKA-9284
> URL: https://issues.apache.org/jira/browse/KAFKA-9284
> Project: Kafka
> Issue Type: Improvement
> Components: documentation, system tests
> Affects Versions: 2.4.0
> Reporter: Ron Dagostino
> Assignee: Ron Dagostino
> Priority: Minor
>
> TLS connectivity to Zookeeper became available in the 3.5.x versions. Now
> with the inclusion of these Zookeeper versions Kafka should supply
> documentation that distills the steps required to take advantage of TLS and
> include systems tests to validate such setups.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
