Status

Current state: "Under Discussion"

Discussion thread: here

JIRA: here

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

The goal is to add kerberos capability to Kafka brokers , to start a Kafka broker with valid
kerberos ticket and accept sasl connections from client with a valid kerberos ticket.

Public Interfaces

• Channel is a wrapper for SocketChannel providing necessary handshake methods and also read(ByteBuffer buf) , write(ByteBuffer buf), write(ByteBuffer[] buf).
• GSSChannel in similar to the work done for SSL here https://issues.apache.org/jira/browse/KAFKA-1684  , provides the necessary read, write operations .
• GSSServerChannel extends GSSChannel to provide server side handshake methods
• GSSBlockingClientChannel extends GSSChannel to provide client side blocking handshake methods. This will be used by BlockingChannel.scala
• GSSClientChannel extends GSSChannel to provide non-blocking client side handshake methods. This will be used by new producer and consumer .
  
  
• User: This class will be used to get the remoteUserId and add it to the Session Object (https://issues.apache.org/jira/browse/KAFKA-1683)
• KafkaPrincipalToLocalPlugin: This is a pluggable class with a default implementation which translates a kerberos principal which looks like "testuser/node1.test.com@EXAMPLE.COM" to "testuser" . Users can provide a their own customized version of PrincipalToLocalPlugin.
• AuthUtils: This class will consists of any utilities needed for SASL and other auth related methods.
• KerberosLoginManager: This is a singleton object . It will use jaas config to login and generates a subject. 

Proposed Changes

we will be using GSS-API to provide authentication and data security services in connection oriented protocols. 

As part of Kerberos/GSS-API implementation we will be using JAAS config to read kerberos ticket and authenticate. More info on JAAS Config

http://docs.oracle.com/javase/7/docs/technotes/guides/security/jaas/JAASRefGuide.html

Proposed JAAS Login config file will look like this

KafkaServer {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="/keytabs/kafka.keytab"
storeKey=true
useTicketCache=false
serviceName="kafka" // this will be used to connect to other brokers for replica management and also controller requests. This should be set to whatever principal that kafka brokers are running.
principal="kafka/_HOST@EXAMPLE.COM";
};
Client {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="/vagrant/keytabs/storm.keytab"
storeKey=true
useTicketCache=false
serviceName="zookeeper"
principal="kafka@EXAMPLE.COM";
}


KafkaServer will be used to authenticate Kafka broker against kerberos
and Client section will be used for zkClient to access kerberos enabled zookeeper cluster.

KafkaClient {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="/keytabs/kafka.keytab"
storeKey=true
useTicketCache=true
serviceName="kafka"
principal="kafkaproducer/_HOST@EXAMPLE.COM";
};

The above config is for any client ( producer, consumer) connecting to kerberos enabled Kafka cluster.
Here serviceName must match the principal name used under KafkaServer.

GSSChannel

SASL Authentication exchange

KafkaClient

1) KafkaClient picks the principal it wants to use by looking at KafkaClient jaas config (example above).

2) Authenticates against KDC (kerberos) using the KafkaClient principal.

3) KafkaClient constructs the service principal name based on the jaas config serviceName

4) KafkaClient initiates challenge/response with KafkaBroker along with KafkaClient principal and service principal . Depending on the KafkaBroker response these challenge/response might continue until it receives COMPLETE from the KafkaBroker.

KafkaBroker

1) KafkaBroker will accept the connection and takes the client and service prinicpal

2) checks if the service principal is same as the one KafkaBroker running with.

3) KafkaBroker checks if the KafkaClient principal is authorized to use the service

4) Returns the response to the client if its authorized or not.

5) Once client is authenticated they can send Kafka requests.

Compatibility, Deprecation, and Migration Plan

As per previous security discussions and multiport work being done as part of this JIRA Unable to render Jira issues macro, execution error. ,

Users/Clients can still communicate with non-secure/non-sasl kafka brokers.

Rejected Alternatives

None