[
https://issues.apache.org/jira/browse/KAFKA-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207625#comment-14207625
]
Gwen Shapira commented on KAFKA-1684:
-------------------------------------
I don't think HBase is the right model here (since its significantly more
complex than what we are trying to do), but lets take a look at what HBase is
doing:
1. HBase has an optional REST API. SSL is only supported on the REST API. Not
across every API the product exposes.
2. The REST API supports SSL on the same port as non-secure. The decision on
whether communication is secured or not is done based on a configuration file.
If the REST API is set to SSL, non-SSL connections are not supported.
3. REST API does not support Kerberos authentication for users. It does take
Kerberos tokens as a way to identify the REST Server itself to the main HBase
servers (Region servers and masters).
4. HBase Region servers and masters support Kerberos and not SSL. Kerberos is
supported on same port as non-secure. To the best of my understanding (based on
this:
http://blog.cloudera.com/blog/2012/09/understanding-user-authentication-and-authorization-in-apache-hbase/)
if security is enabled on the server, non-authenticated clients are denied
access.
All this is very different from what we are trying to achieve for Kafka.
Actually, the fact that we are having a difficult time finding any good model
for what we are trying to do (supporting non-secure, SSL and Kerberos at the
same time on the same APIs and channels) is a bit concerning.
It is definitely possible to implement a single port for SASL and non-secure by
adding an AUTH request to the API (based on what ZK are doing).
I don't know SSL well enough to know if we can use the same port for both SSL
and Kerberos at the same time (i.e. without forcing SSL or Kerberos via
configs).
I still think 3 different ports for the 3 security modes is the simplest
solution.
> Implement TLS/SSL authentication
> --------------------------------
>
> Key: KAFKA-1684
> URL: https://issues.apache.org/jira/browse/KAFKA-1684
> Project: Kafka
> Issue Type: Sub-task
> Components: security
> Affects Versions: 0.9.0
> Reporter: Jay Kreps
> Assignee: Ivan Lyutov
> Attachments: KAFKA-1684.patch
>
>
> Add an SSL port to the configuration and advertise this as part of the
> metadata request.
> If the SSL port is configured the socket server will need to add a second
> Acceptor thread to listen on it. Connections accepted on this port will need
> to go through the SSL handshake prior to being registered with a Processor
> for request processing.
> SSL requests and responses may need to be wrapped or unwrapped using the
> SSLEngine that was initialized by the acceptor. This wrapping and unwrapping
> is very similar to what will need to be done for SASL-based authentication
> schemes. We should have a uniform interface that covers both of these and we
> will need to store the instance in the session with the request. The socket
> server will have to use this object when reading and writing requests. We
> will need to take care with the FetchRequests as the current
> FileChannel.transferTo mechanism will be incompatible with wrap/unwrap so we
> can only use this optimization for unencrypted sockets that don't require
> userspace translation (wrapping).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
