Securing Kafka with zookeeper 3.5.5+ and mTLS

[Dima Brodsky]

Hi,

I was just wondering if the following article:

https://docs.confluent.io/current/kafka/incremental-security-upgrade.html

is still valid when using Zookeeper 3.5.5 with mTLS rather than kerberos?
If it is still valid, what principle is used for the ACL?

Thanks!
ttyl
Dima


-- 
dbrod...@salesforce.com

"The price of reliability is the pursuit of the utmost simplicity.
It is the price which the very rich find most hard to pay." (Sir Antony
Hoare, 1980)

Re: Securing Kafka - Keystore and Truststore question

[Rajini Sivaram]

Raghav,

*My guess about the problem is that I was generate a csr (certificate
signing request), which is different from actually extracting certificate.
Please correct me if I am wrong.*

Yes, that is correct. Use "keytool -exportcert" to extract the certificate.


*To actually address our problem of minimizing key exchanges between our
Kafka Clients (customers) and us (Kafka Brokers), I experimented that if we
generate a keystone and trust store for them, and then ask them to use it
in their client, it works fine. It reduces the number of round trips. Let
me know if something like this is ok or can their be a security breach ?*

The issue with this approach is that you also have access to the customer's
private key. And you need a secure way to transferring this key to the
customer. The standard way of customer generating the key-pair and giving
you only the public certificate avoids these issues.


On Fri, May 19, 2017 at 1:19 PM, Raghav  wrote:

> Rajini
>
> I was generating a certificate (using key tool by first doing -genkey and
> creating a keystore, and then subsequently extracting certificate using
> -centreq) for Kafka client (Producer). Once this certificate was available,
> I was trying to add this certificate to Kafka Broker's trust store. While
> doing this, key tool would not allow to add this certificate to trust store
> of Kafka broker.
>
> My guess about the problem is that I was generate a csr (certificate
> signing request), which is different from actually extracting certificate.
> Please correct me if I am wrong.
>
> To actually address our problem of minimizing key exchanges between our
> Kafka Clients (customers) and us (Kafka Brokers), I experimented that if we
> generate a keystone and trust store for them, and then ask them to use it
> in their client, it works fine. It reduces the number of round trips. Let
> me know if something like this is ok or can their be a security breach ?
>
> Thanks.
>
> Raghav
>
>
>
> On Thu, May 18, 2017 at 10:26 AM, Rajini Sivaram 
> wrote:
>
>> Raghav,
>>
>> If you send me the full command sequence, I can take a look. Also, which
>> JRE are you using?
>>
>> Regards,
>>
>> Rajini
>>
>> On Thu, May 18, 2017 at 12:19 PM, Raghav  wrote:
>>
>>> Rajini
>>>
>>> I just tried this. It turns out that I can't import cert-file by itself
>>> in trust store until it is signed by a CA. Could be because of the format ?
>>> Any idea here ...
>>>
>>> In the above steps, if I sign the server-cert-file and client-cert-file
>>> by a private CA then I can add them to trust store and key store. In this
>>> test, I did not add the CA cert in either keystone or trust store.
>>>
>>> Thanks for all your help.
>>>
>>>
>>>
>>>
>>> On Thu, May 18, 2017 at 8:26 AM, Rajini Sivaram >> > wrote:
>>>
 Raghav,

 Perhaps what you want to do is:

 *You do (for the brokers):*

 Generate key-pair for broker:

 keytool -keystore kafka.server.keystore.jks -alias localhost -validity
 365 -genkey

 Export certificate to a file to send to your customers:

 keytool -exportcert -file server-cert-file -keystore
 kafka.server.keystore.jks -alias localhost


 And you send server-cert-file to your customers.

 Once you get your customer's client-cert-file, you do:

 keytool -importcert -file client-cert-file -keystore
 kafka.server.truststore.jks -alias customerA

 If you are using SSL for inter-broker communication, your broker
 certificate also needs to be in the server truststore:

 keytool -importcert -file server-cert-file -keystore
 kafka.client.truststore.jks -alias broker


 *Your customers do (for the clients):*

 Generate key-pair for client:

 keytool -keystore kafka.client.keystore.jks -alias localhost -validity
 365 -genkey

 Export certificate to a file to send to to you:

 keytool -exportcert -file client-cert-file -keystore
 kafka.client.keystore.jks -alias localhost


 Your customers send you their client-cert-file

 Your customers create their truststore using the broker certificate
 server-cert-file that you send to them:

 keytool -importcert -file server-cert-file -keystore
 kafka.client.truststore.jks -alias broker



 You then configure your brokers with (kafka.server.keystore.jks, ka
 fka.server.truststore.jks).Your customers configure their clients with
 (kafka.client.keystore.jks, kafka.client.truststore.jks).


 Hope that helps.

 Regards,

 Rajini



 On Thu, May 18, 2017 at 10:33 AM, Raghav  wrote:

> Rajini,
>
> Sure, will submit a PR shortly.
>
> Your answer is very helpful, but I think I did not put the question
> correctly. Pardon my ignore but I am still trying to get my ways around
> Kafka security.
>
> I was trying to understand, can we (Kafka Broker) just ad

Re: Securing Kafka - Keystore and Truststore question

[Rajini Sivaram]

Raghav,

If you send me the full command sequence, I can take a look. Also, which
JRE are you using?

Regards,

Rajini

On Thu, May 18, 2017 at 12:19 PM, Raghav  wrote:

> Rajini
>
> I just tried this. It turns out that I can't import cert-file by itself in
> trust store until it is signed by a CA. Could be because of the format ?
> Any idea here ...
>
> In the above steps, if I sign the server-cert-file and client-cert-file by
> a private CA then I can add them to trust store and key store. In this
> test, I did not add the CA cert in either keystone or trust store.
>
> Thanks for all your help.
>
>
>
>
> On Thu, May 18, 2017 at 8:26 AM, Rajini Sivaram 
> wrote:
>
>> Raghav,
>>
>> Perhaps what you want to do is:
>>
>> *You do (for the brokers):*
>>
>> Generate key-pair for broker:
>>
>> keytool -keystore kafka.server.keystore.jks -alias localhost -validity
>> 365 -genkey
>>
>> Export certificate to a file to send to your customers:
>>
>> keytool -exportcert -file server-cert-file -keystore
>> kafka.server.keystore.jks -alias localhost
>>
>>
>> And you send server-cert-file to your customers.
>>
>> Once you get your customer's client-cert-file, you do:
>>
>> keytool -importcert -file client-cert-file -keystore
>> kafka.server.truststore.jks -alias customerA
>>
>> If you are using SSL for inter-broker communication, your broker
>> certificate also needs to be in the server truststore:
>>
>> keytool -importcert -file server-cert-file -keystore
>> kafka.client.truststore.jks -alias broker
>>
>>
>> *Your customers do (for the clients):*
>>
>> Generate key-pair for client:
>>
>> keytool -keystore kafka.client.keystore.jks -alias localhost -validity
>> 365 -genkey
>>
>> Export certificate to a file to send to to you:
>>
>> keytool -exportcert -file client-cert-file -keystore
>> kafka.client.keystore.jks -alias localhost
>>
>>
>> Your customers send you their client-cert-file
>>
>> Your customers create their truststore using the broker certificate
>> server-cert-file that you send to them:
>>
>> keytool -importcert -file server-cert-file -keystore
>> kafka.client.truststore.jks -alias broker
>>
>>
>>
>> You then configure your brokers with (kafka.server.keystore.jks, ka
>> fka.server.truststore.jks).Your customers configure their clients with (
>> kafka.client.keystore.jks, kafka.client.truststore.jks).
>>
>>
>> Hope that helps.
>>
>> Regards,
>>
>> Rajini
>>
>>
>>
>> On Thu, May 18, 2017 at 10:33 AM, Raghav  wrote:
>>
>>> Rajini,
>>>
>>> Sure, will submit a PR shortly.
>>>
>>> Your answer is very helpful, but I think I did not put the question
>>> correctly. Pardon my ignore but I am still trying to get my ways around
>>> Kafka security.
>>>
>>> I was trying to understand, can we (Kafka Broker) just add the
>>> certificate (unsigned or signed) from customer to our trust store without
>>> adding the CA cert to trust store... could that work ?
>>>
>>> 1. Let's say Kafka broker (there is only 1 for simplicity) generates a
>>> keystore and generates a key using the command below
>>>
>>> keytool -keystore kafka.server.keystore.jks -alias localhost -validity 
>>> *365* -genkey
>>>
>>> keytool -keystore kafka.server.keystore.jks -alias localhost -certreq -file 
>>> server-cert-file
>>>
>>> 2. Similarly, Kafka Client (Producer) does the same
>>>
>>> keytool -keystore kafka.client.keystore.jks -alias localhost -validity 
>>> *365* -genkey
>>>
>>> keytool -keystore kafka.client.keystore.jks -alias localhost -certreq -file 
>>> client-cert-file
>>>
>>>
>>> 3. Now, we add *client-cert-file* into the trust store of server, and
>>> *server-cert-file* into the trust store of client. Given that each
>>> trust store has other party's certificate in their trust store, does CA
>>> certificate come into the picture ?
>>>
>>> On Thu, May 18, 2017 at 6:26 AM, Rajini Sivaram >> > wrote:
>>>
 Raghav,

 Yes, you can create a truststore with your customers' certificates and
 vice-versa. It will be best to give your CA certificate to your customers
 and get the CA certificate from each of your customers and add them to your
 broker's truststore. You can both then create additional certificates if
 you need without any changes to your truststore as long as the CA
 certificates are valid. Unlike certificates signed by a trusted authority,
 you will need to add the CAs of every customer to your truststore. Kafka
 brokers don't reload certificates, so if you wanted to add another
 customer's certificate to your truststore, you will need to restart your
 broker.

 Would you like to submit a PR with the information that is missing in
 the Apache Kafka documentation that you think may be useful?

 Regards,

 Rajini

 On Wed, May 17, 2017 at 6:21 PM, Raghav  wrote:

> Another quick question:
>
> Say we chose to add our customer's certificates directly to our
> brokers trust store and vice verse, could that work ? There is no
> documentatio

Re: Securing Kafka - Keystore and Truststore question

[Raghav]

Rajini

I just tried this. It turns out that I can't import cert-file by itself in
trust store until it is signed by a CA. Could be because of the format ?
Any idea here ...

In the above steps, if I sign the server-cert-file and client-cert-file by
a private CA then I can add them to trust store and key store. In this
test, I did not add the CA cert in either keystone or trust store.

Thanks for all your help.




On Thu, May 18, 2017 at 8:26 AM, Rajini Sivaram 
wrote:

> Raghav,
>
> Perhaps what you want to do is:
>
> *You do (for the brokers):*
>
> Generate key-pair for broker:
>
> keytool -keystore kafka.server.keystore.jks -alias localhost -validity 365
> -genkey
>
> Export certificate to a file to send to your customers:
>
> keytool -exportcert -file server-cert-file -keystore
> kafka.server.keystore.jks -alias localhost
>
>
> And you send server-cert-file to your customers.
>
> Once you get your customer's client-cert-file, you do:
>
> keytool -importcert -file client-cert-file -keystore
> kafka.server.truststore.jks -alias customerA
>
> If you are using SSL for inter-broker communication, your broker
> certificate also needs to be in the server truststore:
>
> keytool -importcert -file server-cert-file -keystore
> kafka.client.truststore.jks -alias broker
>
>
> *Your customers do (for the clients):*
>
> Generate key-pair for client:
>
> keytool -keystore kafka.client.keystore.jks -alias localhost -validity 365
> -genkey
>
> Export certificate to a file to send to to you:
>
> keytool -exportcert -file client-cert-file -keystore
> kafka.client.keystore.jks -alias localhost
>
>
> Your customers send you their client-cert-file
>
> Your customers create their truststore using the broker certificate
> server-cert-file that you send to them:
>
> keytool -importcert -file server-cert-file -keystore
> kafka.client.truststore.jks -alias broker
>
>
>
> You then configure your brokers with (kafka.server.keystore.jks, ka
> fka.server.truststore.jks).Your customers configure their clients with (
> kafka.client.keystore.jks, kafka.client.truststore.jks).
>
>
> Hope that helps.
>
> Regards,
>
> Rajini
>
>
>
> On Thu, May 18, 2017 at 10:33 AM, Raghav  wrote:
>
>> Rajini,
>>
>> Sure, will submit a PR shortly.
>>
>> Your answer is very helpful, but I think I did not put the question
>> correctly. Pardon my ignore but I am still trying to get my ways around
>> Kafka security.
>>
>> I was trying to understand, can we (Kafka Broker) just add the
>> certificate (unsigned or signed) from customer to our trust store without
>> adding the CA cert to trust store... could that work ?
>>
>> 1. Let's say Kafka broker (there is only 1 for simplicity) generates a
>> keystore and generates a key using the command below
>>
>> keytool -keystore kafka.server.keystore.jks -alias localhost -validity *365* 
>> -genkey
>>
>> keytool -keystore kafka.server.keystore.jks -alias localhost -certreq -file 
>> server-cert-file
>>
>> 2. Similarly, Kafka Client (Producer) does the same
>>
>> keytool -keystore kafka.client.keystore.jks -alias localhost -validity *365* 
>> -genkey
>>
>> keytool -keystore kafka.client.keystore.jks -alias localhost -certreq -file 
>> client-cert-file
>>
>>
>> 3. Now, we add *client-cert-file* into the trust store of server, and
>> *server-cert-file* into the trust store of client. Given that each trust
>> store has other party's certificate in their trust store, does CA
>> certificate come into the picture ?
>>
>> On Thu, May 18, 2017 at 6:26 AM, Rajini Sivaram 
>> wrote:
>>
>>> Raghav,
>>>
>>> Yes, you can create a truststore with your customers' certificates and
>>> vice-versa. It will be best to give your CA certificate to your customers
>>> and get the CA certificate from each of your customers and add them to your
>>> broker's truststore. You can both then create additional certificates if
>>> you need without any changes to your truststore as long as the CA
>>> certificates are valid. Unlike certificates signed by a trusted authority,
>>> you will need to add the CAs of every customer to your truststore. Kafka
>>> brokers don't reload certificates, so if you wanted to add another
>>> customer's certificate to your truststore, you will need to restart your
>>> broker.
>>>
>>> Would you like to submit a PR with the information that is missing in
>>> the Apache Kafka documentation that you think may be useful?
>>>
>>> Regards,
>>>
>>> Rajini
>>>
>>> On Wed, May 17, 2017 at 6:21 PM, Raghav  wrote:
>>>
 Another quick question:

 Say we chose to add our customer's certificates directly to our brokers
 trust store and vice verse, could that work ? There is no documentation on
 Kafka or Confluent site for this ?

 Thanks.


 On Wed, May 17, 2017 at 1:56 PM, Rajini Sivaram <
 rajinisiva...@gmail.com> wrote:

> Raghav,
>
> 1. Yes, your customers can use certificates signed by a trusted
> authority. You can simply omit the truststore configuration for your 
>

Re: Securing Kafka - Keystore and Truststore question

[Rajini Sivaram]

Raghav,

Perhaps what you want to do is:

*You do (for the brokers):*

Generate key-pair for broker:

keytool -keystore kafka.server.keystore.jks -alias localhost -validity 365
-genkey

Export certificate to a file to send to your customers:

keytool -exportcert -file server-cert-file -keystore
kafka.server.keystore.jks -alias localhost


And you send server-cert-file to your customers.

Once you get your customer's client-cert-file, you do:

keytool -importcert -file client-cert-file -keystore
kafka.server.truststore.jks -alias customerA

If you are using SSL for inter-broker communication, your broker
certificate also needs to be in the server truststore:

keytool -importcert -file server-cert-file -keystore
kafka.client.truststore.jks -alias broker


*Your customers do (for the clients):*

Generate key-pair for client:

keytool -keystore kafka.client.keystore.jks -alias localhost -validity 365
-genkey

Export certificate to a file to send to to you:

keytool -exportcert -file client-cert-file -keystore
kafka.client.keystore.jks -alias localhost


Your customers send you their client-cert-file

Your customers create their truststore using the broker certificate
server-cert-file that you send to them:

keytool -importcert -file server-cert-file -keystore
kafka.client.truststore.jks -alias broker



You then configure your brokers with (kafka.server.keystore.jks,
kafka.server.truststore.jks).Your customers configure their clients with (
kafka.client.keystore.jks, kafka.client.truststore.jks).


Hope that helps.

Regards,

Rajini



On Thu, May 18, 2017 at 10:33 AM, Raghav  wrote:

> Rajini,
>
> Sure, will submit a PR shortly.
>
> Your answer is very helpful, but I think I did not put the question
> correctly. Pardon my ignore but I am still trying to get my ways around
> Kafka security.
>
> I was trying to understand, can we (Kafka Broker) just add the certificate
> (unsigned or signed) from customer to our trust store without adding the CA
> cert to trust store... could that work ?
>
> 1. Let's say Kafka broker (there is only 1 for simplicity) generates a
> keystore and generates a key using the command below
>
> keytool -keystore kafka.server.keystore.jks -alias localhost -validity *365* 
> -genkey
>
> keytool -keystore kafka.server.keystore.jks -alias localhost -certreq -file 
> server-cert-file
>
> 2. Similarly, Kafka Client (Producer) does the same
>
> keytool -keystore kafka.client.keystore.jks -alias localhost -validity *365* 
> -genkey
>
> keytool -keystore kafka.client.keystore.jks -alias localhost -certreq -file 
> client-cert-file
>
>
> 3. Now, we add *client-cert-file* into the trust store of server, and
> *server-cert-file* into the trust store of client. Given that each trust
> store has other party's certificate in their trust store, does CA
> certificate come into the picture ?
>
> On Thu, May 18, 2017 at 6:26 AM, Rajini Sivaram 
> wrote:
>
>> Raghav,
>>
>> Yes, you can create a truststore with your customers' certificates and
>> vice-versa. It will be best to give your CA certificate to your customers
>> and get the CA certificate from each of your customers and add them to your
>> broker's truststore. You can both then create additional certificates if
>> you need without any changes to your truststore as long as the CA
>> certificates are valid. Unlike certificates signed by a trusted authority,
>> you will need to add the CAs of every customer to your truststore. Kafka
>> brokers don't reload certificates, so if you wanted to add another
>> customer's certificate to your truststore, you will need to restart your
>> broker.
>>
>> Would you like to submit a PR with the information that is missing in the
>> Apache Kafka documentation that you think may be useful?
>>
>> Regards,
>>
>> Rajini
>>
>> On Wed, May 17, 2017 at 6:21 PM, Raghav  wrote:
>>
>>> Another quick question:
>>>
>>> Say we chose to add our customer's certificates directly to our brokers
>>> trust store and vice verse, could that work ? There is no documentation on
>>> Kafka or Confluent site for this ?
>>>
>>> Thanks.
>>>
>>>
>>> On Wed, May 17, 2017 at 1:56 PM, Rajini Sivaram >> > wrote:
>>>
 Raghav,

 1. Yes, your customers can use certificates signed by a trusted
 authority. You can simply omit the truststore configuration for your broker
 in server.properties, and Kafka would use the default, which will trust the
 client certificates. If your brokers are using SSL for inter-broker
 communication and you are still using your private CA for broker's
 keystore, then you will need two separate endpoints in your listener
 configuration, one for your customer's clients and another for inter-broker
 communication so that you can specify a truststore with your private
 ca-cert for your broker connections.

 2. Yes, all the commands can specify password on the command line, so
 you should be able to generate all the stores using a script without any
 interactions.

Re: Securing Kafka - Keystore and Truststore question

[Raghav]

Rajini,

Sure, will submit a PR shortly.

Your answer is very helpful, but I think I did not put the question
correctly. Pardon my ignore but I am still trying to get my ways around
Kafka security.

I was trying to understand, can we (Kafka Broker) just add the certificate
(unsigned or signed) from customer to our trust store without adding the CA
cert to trust store... could that work ?

1. Let's say Kafka broker (there is only 1 for simplicity) generates a
keystore and generates a key using the command below

keytool -keystore kafka.server.keystore.jks -alias localhost -validity
*365* -genkey

keytool -keystore kafka.server.keystore.jks -alias localhost -certreq
-file server-cert-file

2. Similarly, Kafka Client (Producer) does the same

keytool -keystore kafka.client.keystore.jks -alias localhost -validity
*365* -genkey

keytool -keystore kafka.client.keystore.jks -alias localhost -certreq
-file client-cert-file


3. Now, we add *client-cert-file* into the trust store of server, and
*server-cert-file* into the trust store of client. Given that each trust
store has other party's certificate in their trust store, does CA
certificate come into the picture ?

On Thu, May 18, 2017 at 6:26 AM, Rajini Sivaram 
wrote:

> Raghav,
>
> Yes, you can create a truststore with your customers' certificates and
> vice-versa. It will be best to give your CA certificate to your customers
> and get the CA certificate from each of your customers and add them to your
> broker's truststore. You can both then create additional certificates if
> you need without any changes to your truststore as long as the CA
> certificates are valid. Unlike certificates signed by a trusted authority,
> you will need to add the CAs of every customer to your truststore. Kafka
> brokers don't reload certificates, so if you wanted to add another
> customer's certificate to your truststore, you will need to restart your
> broker.
>
> Would you like to submit a PR with the information that is missing in the
> Apache Kafka documentation that you think may be useful?
>
> Regards,
>
> Rajini
>
> On Wed, May 17, 2017 at 6:21 PM, Raghav  wrote:
>
>> Another quick question:
>>
>> Say we chose to add our customer's certificates directly to our brokers
>> trust store and vice verse, could that work ? There is no documentation on
>> Kafka or Confluent site for this ?
>>
>> Thanks.
>>
>>
>> On Wed, May 17, 2017 at 1:56 PM, Rajini Sivaram 
>> wrote:
>>
>>> Raghav,
>>>
>>> 1. Yes, your customers can use certificates signed by a trusted
>>> authority. You can simply omit the truststore configuration for your broker
>>> in server.properties, and Kafka would use the default, which will trust the
>>> client certificates. If your brokers are using SSL for inter-broker
>>> communication and you are still using your private CA for broker's
>>> keystore, then you will need two separate endpoints in your listener
>>> configuration, one for your customer's clients and another for inter-broker
>>> communication so that you can specify a truststore with your private
>>> ca-cert for your broker connections.
>>>
>>> 2. Yes, all the commands can specify password on the command line, so
>>> you should be able to generate all the stores using a script without any
>>> interactions.
>>>
>>> Regards,
>>>
>>> Rajini
>>>
>>>
>>> On Wed, May 17, 2017 at 2:49 PM, Raghav  wrote:
>>>
 One follow up questions Rajini:

 1. Can we use some other mechanism like have our customer's use a well
 known CA which JKS understands, and in that case we don't have to ask our
 customers to do this certificate-in and certificate-out thing ? I am just
 trying to understand if we can make our customer's workflow easier.
 Anything else that you can suggest here

 2. Can we automate the key gen steps mentioned on apache website and
 adding to keystone and trust store so that we don't have to manually supply
 password ? Currently, everytime I tried to do steps mentioned in
 https://kafka.apache.org/documentation/#security I have to manually
 give password. It would be great if we can automate this process either
 through script or Java code. Any suggestions ...


 Many thanks.

 On Tue, May 16, 2017 at 10:58 AM, Raghav  wrote:

> Many thanks, Rajini.
>
> On Tue, May 16, 2017 at 8:43 AM, Rajini Sivaram <
> rajinisiva...@gmail.com> wrote:
>
>> Hi Raghav,
>>
>> If your Kafka broker is configured with *ssl.client.auth=required,* your
>> customer's clients need to provide a keystore. In any case, they need a
>> truststore since your broker is using SSL. For the truststore, you can
>> given them ca-cert, as you mentioned. Client keystore contains a
>> certificate and a private key.
>>
>> In the round-trip you described, customers generate the keys and give
>> you the certificate signing request, keeping their private key private. 
>> You
>> then send them back a 

Re: Securing Kafka - Keystore and Truststore question

[Rajini Sivaram]

Raghav,

Yes, you can create a truststore with your customers' certificates and
vice-versa. It will be best to give your CA certificate to your customers
and get the CA certificate from each of your customers and add them to your
broker's truststore. You can both then create additional certificates if
you need without any changes to your truststore as long as the CA
certificates are valid. Unlike certificates signed by a trusted authority,
you will need to add the CAs of every customer to your truststore. Kafka
brokers don't reload certificates, so if you wanted to add another
customer's certificate to your truststore, you will need to restart your
broker.

Would you like to submit a PR with the information that is missing in the
Apache Kafka documentation that you think may be useful?

Regards,

Rajini

On Wed, May 17, 2017 at 6:21 PM, Raghav  wrote:

> Another quick question:
>
> Say we chose to add our customer's certificates directly to our brokers
> trust store and vice verse, could that work ? There is no documentation on
> Kafka or Confluent site for this ?
>
> Thanks.
>
>
> On Wed, May 17, 2017 at 1:56 PM, Rajini Sivaram 
> wrote:
>
>> Raghav,
>>
>> 1. Yes, your customers can use certificates signed by a trusted
>> authority. You can simply omit the truststore configuration for your broker
>> in server.properties, and Kafka would use the default, which will trust the
>> client certificates. If your brokers are using SSL for inter-broker
>> communication and you are still using your private CA for broker's
>> keystore, then you will need two separate endpoints in your listener
>> configuration, one for your customer's clients and another for inter-broker
>> communication so that you can specify a truststore with your private
>> ca-cert for your broker connections.
>>
>> 2. Yes, all the commands can specify password on the command line, so you
>> should be able to generate all the stores using a script without any
>> interactions.
>>
>> Regards,
>>
>> Rajini
>>
>>
>> On Wed, May 17, 2017 at 2:49 PM, Raghav  wrote:
>>
>>> One follow up questions Rajini:
>>>
>>> 1. Can we use some other mechanism like have our customer's use a well
>>> known CA which JKS understands, and in that case we don't have to ask our
>>> customers to do this certificate-in and certificate-out thing ? I am just
>>> trying to understand if we can make our customer's workflow easier.
>>> Anything else that you can suggest here
>>>
>>> 2. Can we automate the key gen steps mentioned on apache website and
>>> adding to keystone and trust store so that we don't have to manually supply
>>> password ? Currently, everytime I tried to do steps mentioned in
>>> https://kafka.apache.org/documentation/#security I have to manually
>>> give password. It would be great if we can automate this process either
>>> through script or Java code. Any suggestions ...
>>>
>>>
>>> Many thanks.
>>>
>>> On Tue, May 16, 2017 at 10:58 AM, Raghav  wrote:
>>>
 Many thanks, Rajini.

 On Tue, May 16, 2017 at 8:43 AM, Rajini Sivaram <
 rajinisiva...@gmail.com> wrote:

> Hi Raghav,
>
> If your Kafka broker is configured with *ssl.client.auth=required,* your
> customer's clients need to provide a keystore. In any case, they need a
> truststore since your broker is using SSL. For the truststore, you can
> given them ca-cert, as you mentioned. Client keystore contains a
> certificate and a private key.
>
> In the round-trip you described, customers generate the keys and give
> you the certificate signing request, keeping their private key private. 
> You
> then send them back a signed certificate that goes into their keystore.
> This is the standard way of signing and is secure.
>
> In the single step scenario that you described, you generate the
> customer's key-pair consisting of certificate and private key. You then
> need to send them both the signed certificate and the private key. This is
> less secure. Unlike the round-trip, you now have the private key of the
> customer.
>
> Regards,
>
> Rajini
>
>
> On Tue, May 16, 2017 at 10:47 AM, Raghav 
> wrote:
>
>> Hi Rajini
>>
>> This was very helpful. I have another questions on similar lines.
>>
>> We host Kafka Broker, and we also have our own private CA. We want
>> our customers to setup their Kafka Clients (Producer and Consumer) using
>> SSL using *ssl.client.auth=required*.
>>
>> Is there a way, we can generate certificate for our clients, sign it
>> using our private CA, and then hand over our customers these  two
>> certificates (1. ca-cert 2. cert-signed), which if they add to their
>> keystroke and truststore, they can send message to our Kafka brokers 
>> while
>> keeping *ssl.client.auth=required*.
>>
>> We are looking to minimize our customer's pre-setup steps. For
>> example in normal scenario, customer

Re: Securing Kafka - Keystore and Truststore question

[Raghav]

Another quick question:

Say we chose to add our customer's certificates directly to our brokers
trust store and vice verse, could that work ? There is no documentation on
Kafka or Confluent site for this ?

Thanks.


On Wed, May 17, 2017 at 1:56 PM, Rajini Sivaram 
wrote:

> Raghav,
>
> 1. Yes, your customers can use certificates signed by a trusted authority.
> You can simply omit the truststore configuration for your broker in
> server.properties, and Kafka would use the default, which will trust the
> client certificates. If your brokers are using SSL for inter-broker
> communication and you are still using your private CA for broker's
> keystore, then you will need two separate endpoints in your listener
> configuration, one for your customer's clients and another for inter-broker
> communication so that you can specify a truststore with your private
> ca-cert for your broker connections.
>
> 2. Yes, all the commands can specify password on the command line, so you
> should be able to generate all the stores using a script without any
> interactions.
>
> Regards,
>
> Rajini
>
>
> On Wed, May 17, 2017 at 2:49 PM, Raghav  wrote:
>
>> One follow up questions Rajini:
>>
>> 1. Can we use some other mechanism like have our customer's use a well
>> known CA which JKS understands, and in that case we don't have to ask our
>> customers to do this certificate-in and certificate-out thing ? I am just
>> trying to understand if we can make our customer's workflow easier.
>> Anything else that you can suggest here
>>
>> 2. Can we automate the key gen steps mentioned on apache website and
>> adding to keystone and trust store so that we don't have to manually supply
>> password ? Currently, everytime I tried to do steps mentioned in
>> https://kafka.apache.org/documentation/#security I have to manually give
>> password. It would be great if we can automate this process either through
>> script or Java code. Any suggestions ...
>>
>>
>> Many thanks.
>>
>> On Tue, May 16, 2017 at 10:58 AM, Raghav  wrote:
>>
>>> Many thanks, Rajini.
>>>
>>> On Tue, May 16, 2017 at 8:43 AM, Rajini Sivaram >> > wrote:
>>>
 Hi Raghav,

 If your Kafka broker is configured with *ssl.client.auth=required,* your
 customer's clients need to provide a keystore. In any case, they need a
 truststore since your broker is using SSL. For the truststore, you can
 given them ca-cert, as you mentioned. Client keystore contains a
 certificate and a private key.

 In the round-trip you described, customers generate the keys and give
 you the certificate signing request, keeping their private key private. You
 then send them back a signed certificate that goes into their keystore.
 This is the standard way of signing and is secure.

 In the single step scenario that you described, you generate the
 customer's key-pair consisting of certificate and private key. You then
 need to send them both the signed certificate and the private key. This is
 less secure. Unlike the round-trip, you now have the private key of the
 customer.

 Regards,

 Rajini


 On Tue, May 16, 2017 at 10:47 AM, Raghav  wrote:

> Hi Rajini
>
> This was very helpful. I have another questions on similar lines.
>
> We host Kafka Broker, and we also have our own private CA. We want our
> customers to setup their Kafka Clients (Producer and Consumer) using SSL
> using *ssl.client.auth=required*.
>
> Is there a way, we can generate certificate for our clients, sign it
> using our private CA, and then hand over our customers these  two
> certificates (1. ca-cert 2. cert-signed), which if they add to their
> keystroke and truststore, they can send message to our Kafka brokers while
> keeping *ssl.client.auth=required*.
>
> We are looking to minimize our customer's pre-setup steps. For example
> in normal scenario, customers will need to generate certificate, and hand
> over their certificate request to our private CA, which we then sign it,
> and send them signed certificate and private CA's certificate. So there is
> one round trip. Just wondering if we can reduce this 2 step into 1 step.
>
> Thanks.
>
>
>
>
>
>
>
>
>
>
>
> On Fri, May 12, 2017 at 8:53 AM, Rajini Sivaram <
> rajinisiva...@gmail.com> wrote:
>
>> Raqhav,
>>
>> 1. Clients need a keystore if you are using TLS client
>> authentication. To
>> enable client authentication, you need to configure ssl.client.auth in
>> server.properties. This can be set to required|requested|none. If you
>> don't
>> enable client authentication, any client will be able to connect to
>> your
>> broker. You could alternatively use SASL for client authentication.
>> .
>> 2. Client keystore is mandatory if ssl.client.auth=required, optional
>> for
>> reques

Re: Securing Kafka - Keystore and Truststore question

[Rajini Sivaram]

Raghav,

1. Yes, your customers can use certificates signed by a trusted authority.
You can simply omit the truststore configuration for your broker in
server.properties, and Kafka would use the default, which will trust the
client certificates. If your brokers are using SSL for inter-broker
communication and you are still using your private CA for broker's
keystore, then you will need two separate endpoints in your listener
configuration, one for your customer's clients and another for inter-broker
communication so that you can specify a truststore with your private
ca-cert for your broker connections.

2. Yes, all the commands can specify password on the command line, so you
should be able to generate all the stores using a script without any
interactions.

Regards,

Rajini


On Wed, May 17, 2017 at 2:49 PM, Raghav  wrote:

> One follow up questions Rajini:
>
> 1. Can we use some other mechanism like have our customer's use a well
> known CA which JKS understands, and in that case we don't have to ask our
> customers to do this certificate-in and certificate-out thing ? I am just
> trying to understand if we can make our customer's workflow easier.
> Anything else that you can suggest here
>
> 2. Can we automate the key gen steps mentioned on apache website and
> adding to keystone and trust store so that we don't have to manually supply
> password ? Currently, everytime I tried to do steps mentioned in
> https://kafka.apache.org/documentation/#security I have to manually give
> password. It would be great if we can automate this process either through
> script or Java code. Any suggestions ...
>
>
> Many thanks.
>
> On Tue, May 16, 2017 at 10:58 AM, Raghav  wrote:
>
>> Many thanks, Rajini.
>>
>> On Tue, May 16, 2017 at 8:43 AM, Rajini Sivaram 
>> wrote:
>>
>>> Hi Raghav,
>>>
>>> If your Kafka broker is configured with *ssl.client.auth=required,* your
>>> customer's clients need to provide a keystore. In any case, they need a
>>> truststore since your broker is using SSL. For the truststore, you can
>>> given them ca-cert, as you mentioned. Client keystore contains a
>>> certificate and a private key.
>>>
>>> In the round-trip you described, customers generate the keys and give
>>> you the certificate signing request, keeping their private key private. You
>>> then send them back a signed certificate that goes into their keystore.
>>> This is the standard way of signing and is secure.
>>>
>>> In the single step scenario that you described, you generate the
>>> customer's key-pair consisting of certificate and private key. You then
>>> need to send them both the signed certificate and the private key. This is
>>> less secure. Unlike the round-trip, you now have the private key of the
>>> customer.
>>>
>>> Regards,
>>>
>>> Rajini
>>>
>>>
>>> On Tue, May 16, 2017 at 10:47 AM, Raghav  wrote:
>>>
 Hi Rajini

 This was very helpful. I have another questions on similar lines.

 We host Kafka Broker, and we also have our own private CA. We want our
 customers to setup their Kafka Clients (Producer and Consumer) using SSL
 using *ssl.client.auth=required*.

 Is there a way, we can generate certificate for our clients, sign it
 using our private CA, and then hand over our customers these  two
 certificates (1. ca-cert 2. cert-signed), which if they add to their
 keystroke and truststore, they can send message to our Kafka brokers while
 keeping *ssl.client.auth=required*.

 We are looking to minimize our customer's pre-setup steps. For example
 in normal scenario, customers will need to generate certificate, and hand
 over their certificate request to our private CA, which we then sign it,
 and send them signed certificate and private CA's certificate. So there is
 one round trip. Just wondering if we can reduce this 2 step into 1 step.

 Thanks.











 On Fri, May 12, 2017 at 8:53 AM, Rajini Sivaram <
 rajinisiva...@gmail.com> wrote:

> Raqhav,
>
> 1. Clients need a keystore if you are using TLS client authentication.
> To
> enable client authentication, you need to configure ssl.client.auth in
> server.properties. This can be set to required|requested|none. If you
> don't
> enable client authentication, any client will be able to connect to
> your
> broker. You could alternatively use SASL for client authentication.
> .
> 2. Client keystore is mandatory if ssl.client.auth=required, optional
> for
> requested and not used for none. The truststore configured on the
> client is
> used to authenticate the server. So you have to provide it unless your
> broker is using certificates signed by a trusted authority.
>
> Hope that helps.
>
> Rajini
>
> On Fri, May 12, 2017 at 11:35 AM, Raghav 
> wrote:
>
> > Hi
> >
> > I read the documentation here:
> > https://

Re: Securing Kafka - Keystore and Truststore question

[Raghav]

One follow up questions Rajini:

1. Can we use some other mechanism like have our customer's use a well
known CA which JKS understands, and in that case we don't have to ask our
customers to do this certificate-in and certificate-out thing ? I am just
trying to understand if we can make our customer's workflow easier.
Anything else that you can suggest here

2. Can we automate the key gen steps mentioned on apache website and adding
to keystone and trust store so that we don't have to manually supply
password ? Currently, everytime I tried to do steps mentioned in
https://kafka.apache.org/documentation/#security I have to manually give
password. It would be great if we can automate this process either through
script or Java code. Any suggestions ...


Many thanks.

On Tue, May 16, 2017 at 10:58 AM, Raghav  wrote:

> Many thanks, Rajini.
>
> On Tue, May 16, 2017 at 8:43 AM, Rajini Sivaram 
> wrote:
>
>> Hi Raghav,
>>
>> If your Kafka broker is configured with *ssl.client.auth=required,* your
>> customer's clients need to provide a keystore. In any case, they need a
>> truststore since your broker is using SSL. For the truststore, you can
>> given them ca-cert, as you mentioned. Client keystore contains a
>> certificate and a private key.
>>
>> In the round-trip you described, customers generate the keys and give you
>> the certificate signing request, keeping their private key private. You
>> then send them back a signed certificate that goes into their keystore.
>> This is the standard way of signing and is secure.
>>
>> In the single step scenario that you described, you generate the
>> customer's key-pair consisting of certificate and private key. You then
>> need to send them both the signed certificate and the private key. This is
>> less secure. Unlike the round-trip, you now have the private key of the
>> customer.
>>
>> Regards,
>>
>> Rajini
>>
>>
>> On Tue, May 16, 2017 at 10:47 AM, Raghav  wrote:
>>
>>> Hi Rajini
>>>
>>> This was very helpful. I have another questions on similar lines.
>>>
>>> We host Kafka Broker, and we also have our own private CA. We want our
>>> customers to setup their Kafka Clients (Producer and Consumer) using SSL
>>> using *ssl.client.auth=required*.
>>>
>>> Is there a way, we can generate certificate for our clients, sign it
>>> using our private CA, and then hand over our customers these  two
>>> certificates (1. ca-cert 2. cert-signed), which if they add to their
>>> keystroke and truststore, they can send message to our Kafka brokers while
>>> keeping *ssl.client.auth=required*.
>>>
>>> We are looking to minimize our customer's pre-setup steps. For example
>>> in normal scenario, customers will need to generate certificate, and hand
>>> over their certificate request to our private CA, which we then sign it,
>>> and send them signed certificate and private CA's certificate. So there is
>>> one round trip. Just wondering if we can reduce this 2 step into 1 step.
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, May 12, 2017 at 8:53 AM, Rajini Sivaram >> > wrote:
>>>
 Raqhav,

 1. Clients need a keystore if you are using TLS client authentication.
 To
 enable client authentication, you need to configure ssl.client.auth in
 server.properties. This can be set to required|requested|none. If you
 don't
 enable client authentication, any client will be able to connect to your
 broker. You could alternatively use SASL for client authentication.
 .
 2. Client keystore is mandatory if ssl.client.auth=required, optional
 for
 requested and not used for none. The truststore configured on the
 client is
 used to authenticate the server. So you have to provide it unless your
 broker is using certificates signed by a trusted authority.

 Hope that helps.

 Rajini

 On Fri, May 12, 2017 at 11:35 AM, Raghav  wrote:

 > Hi
 >
 > I read the documentation here:
 > https://kafka.apache.org/documentation/#security_ssl
 >
 > I have few questions about trust store and keystore based on this
 scenario:
 >
 > We have 5 Kafka Brokers in our cluster. We want our clients to write
 to our
 > Kafka brokers in a secure way. Suppose, we also host a private CA as
 > mentioned in the documentation above, and provide our clients the
 *ca-cert*
 > file, which they add it to their trust store.
 >
 > 1. Do we require our clients to generate their certificate and have it
 > signed by our private CA, and add it to their keystore?
 >
 > 2. When is keystore used by clients, and when is truststore used by
 clients
 > ?
 >
 >
 > Thanks.
 >
 > --
 > R
 >

>>>
>>>
>>>
>>> --
>>> Raghav
>>>
>>
>>
>
>
> --
> Raghav
>



-- 
Raghav

Re: Securing Kafka - Keystore and Truststore question

[Raghav]

Many thanks, Rajini.

On Tue, May 16, 2017 at 8:43 AM, Rajini Sivaram 
wrote:

> Hi Raghav,
>
> If your Kafka broker is configured with *ssl.client.auth=required,* your
> customer's clients need to provide a keystore. In any case, they need a
> truststore since your broker is using SSL. For the truststore, you can
> given them ca-cert, as you mentioned. Client keystore contains a
> certificate and a private key.
>
> In the round-trip you described, customers generate the keys and give you
> the certificate signing request, keeping their private key private. You
> then send them back a signed certificate that goes into their keystore.
> This is the standard way of signing and is secure.
>
> In the single step scenario that you described, you generate the
> customer's key-pair consisting of certificate and private key. You then
> need to send them both the signed certificate and the private key. This is
> less secure. Unlike the round-trip, you now have the private key of the
> customer.
>
> Regards,
>
> Rajini
>
>
> On Tue, May 16, 2017 at 10:47 AM, Raghav  wrote:
>
>> Hi Rajini
>>
>> This was very helpful. I have another questions on similar lines.
>>
>> We host Kafka Broker, and we also have our own private CA. We want our
>> customers to setup their Kafka Clients (Producer and Consumer) using SSL
>> using *ssl.client.auth=required*.
>>
>> Is there a way, we can generate certificate for our clients, sign it
>> using our private CA, and then hand over our customers these  two
>> certificates (1. ca-cert 2. cert-signed), which if they add to their
>> keystroke and truststore, they can send message to our Kafka brokers while
>> keeping *ssl.client.auth=required*.
>>
>> We are looking to minimize our customer's pre-setup steps. For example in
>> normal scenario, customers will need to generate certificate, and hand over
>> their certificate request to our private CA, which we then sign it, and
>> send them signed certificate and private CA's certificate. So there is one
>> round trip. Just wondering if we can reduce this 2 step into 1 step.
>>
>> Thanks.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, May 12, 2017 at 8:53 AM, Rajini Sivaram 
>> wrote:
>>
>>> Raqhav,
>>>
>>> 1. Clients need a keystore if you are using TLS client authentication. To
>>> enable client authentication, you need to configure ssl.client.auth in
>>> server.properties. This can be set to required|requested|none. If you
>>> don't
>>> enable client authentication, any client will be able to connect to your
>>> broker. You could alternatively use SASL for client authentication.
>>> .
>>> 2. Client keystore is mandatory if ssl.client.auth=required, optional for
>>> requested and not used for none. The truststore configured on the client
>>> is
>>> used to authenticate the server. So you have to provide it unless your
>>> broker is using certificates signed by a trusted authority.
>>>
>>> Hope that helps.
>>>
>>> Rajini
>>>
>>> On Fri, May 12, 2017 at 11:35 AM, Raghav  wrote:
>>>
>>> > Hi
>>> >
>>> > I read the documentation here:
>>> > https://kafka.apache.org/documentation/#security_ssl
>>> >
>>> > I have few questions about trust store and keystore based on this
>>> scenario:
>>> >
>>> > We have 5 Kafka Brokers in our cluster. We want our clients to write
>>> to our
>>> > Kafka brokers in a secure way. Suppose, we also host a private CA as
>>> > mentioned in the documentation above, and provide our clients the
>>> *ca-cert*
>>> > file, which they add it to their trust store.
>>> >
>>> > 1. Do we require our clients to generate their certificate and have it
>>> > signed by our private CA, and add it to their keystore?
>>> >
>>> > 2. When is keystore used by clients, and when is truststore used by
>>> clients
>>> > ?
>>> >
>>> >
>>> > Thanks.
>>> >
>>> > --
>>> > R
>>> >
>>>
>>
>>
>>
>> --
>> Raghav
>>
>
>


-- 
Raghav

Re: Securing Kafka - Keystore and Truststore question

[Rajini Sivaram]

Hi Raghav,

If your Kafka broker is configured with *ssl.client.auth=required,* your
customer's clients need to provide a keystore. In any case, they need a
truststore since your broker is using SSL. For the truststore, you can
given them ca-cert, as you mentioned. Client keystore contains a
certificate and a private key.

In the round-trip you described, customers generate the keys and give you
the certificate signing request, keeping their private key private. You
then send them back a signed certificate that goes into their keystore.
This is the standard way of signing and is secure.

In the single step scenario that you described, you generate the customer's
key-pair consisting of certificate and private key. You then need to send
them both the signed certificate and the private key. This is less secure.
Unlike the round-trip, you now have the private key of the customer.

Regards,

Rajini


On Tue, May 16, 2017 at 10:47 AM, Raghav  wrote:

> Hi Rajini
>
> This was very helpful. I have another questions on similar lines.
>
> We host Kafka Broker, and we also have our own private CA. We want our
> customers to setup their Kafka Clients (Producer and Consumer) using SSL
> using *ssl.client.auth=required*.
>
> Is there a way, we can generate certificate for our clients, sign it using
> our private CA, and then hand over our customers these  two certificates
> (1. ca-cert 2. cert-signed), which if they add to their keystroke and
> truststore, they can send message to our Kafka brokers while keeping
> *ssl.client.auth=required*.
>
> We are looking to minimize our customer's pre-setup steps. For example in
> normal scenario, customers will need to generate certificate, and hand over
> their certificate request to our private CA, which we then sign it, and
> send them signed certificate and private CA's certificate. So there is one
> round trip. Just wondering if we can reduce this 2 step into 1 step.
>
> Thanks.
>
>
>
>
>
>
>
>
>
>
>
> On Fri, May 12, 2017 at 8:53 AM, Rajini Sivaram 
> wrote:
>
>> Raqhav,
>>
>> 1. Clients need a keystore if you are using TLS client authentication. To
>> enable client authentication, you need to configure ssl.client.auth in
>> server.properties. This can be set to required|requested|none. If you
>> don't
>> enable client authentication, any client will be able to connect to your
>> broker. You could alternatively use SASL for client authentication.
>> .
>> 2. Client keystore is mandatory if ssl.client.auth=required, optional for
>> requested and not used for none. The truststore configured on the client
>> is
>> used to authenticate the server. So you have to provide it unless your
>> broker is using certificates signed by a trusted authority.
>>
>> Hope that helps.
>>
>> Rajini
>>
>> On Fri, May 12, 2017 at 11:35 AM, Raghav  wrote:
>>
>> > Hi
>> >
>> > I read the documentation here:
>> > https://kafka.apache.org/documentation/#security_ssl
>> >
>> > I have few questions about trust store and keystore based on this
>> scenario:
>> >
>> > We have 5 Kafka Brokers in our cluster. We want our clients to write to
>> our
>> > Kafka brokers in a secure way. Suppose, we also host a private CA as
>> > mentioned in the documentation above, and provide our clients the
>> *ca-cert*
>> > file, which they add it to their trust store.
>> >
>> > 1. Do we require our clients to generate their certificate and have it
>> > signed by our private CA, and add it to their keystore?
>> >
>> > 2. When is keystore used by clients, and when is truststore used by
>> clients
>> > ?
>> >
>> >
>> > Thanks.
>> >
>> > --
>> > R
>> >
>>
>
>
>
> --
> Raghav
>

Re: Securing Kafka - Keystore and Truststore question

[Raghav]

Hi Rajini

This was very helpful. I have another questions on similar lines.

We host Kafka Broker, and we also have our own private CA. We want our
customers to setup their Kafka Clients (Producer and Consumer) using SSL
using *ssl.client.auth=required*.

Is there a way, we can generate certificate for our clients, sign it using
our private CA, and then hand over our customers these  two certificates
(1. ca-cert 2. cert-signed), which if they add to their keystroke and
truststore, they can send message to our Kafka brokers while keeping
*ssl.client.auth=required*.

We are looking to minimize our customer's pre-setup steps. For example in
normal scenario, customers will need to generate certificate, and hand over
their certificate request to our private CA, which we then sign it, and
send them signed certificate and private CA's certificate. So there is one
round trip. Just wondering if we can reduce this 2 step into 1 step.

Thanks.











On Fri, May 12, 2017 at 8:53 AM, Rajini Sivaram 
wrote:

> Raqhav,
>
> 1. Clients need a keystore if you are using TLS client authentication. To
> enable client authentication, you need to configure ssl.client.auth in
> server.properties. This can be set to required|requested|none. If you don't
> enable client authentication, any client will be able to connect to your
> broker. You could alternatively use SASL for client authentication.
> .
> 2. Client keystore is mandatory if ssl.client.auth=required, optional for
> requested and not used for none. The truststore configured on the client is
> used to authenticate the server. So you have to provide it unless your
> broker is using certificates signed by a trusted authority.
>
> Hope that helps.
>
> Rajini
>
> On Fri, May 12, 2017 at 11:35 AM, Raghav  wrote:
>
> > Hi
> >
> > I read the documentation here:
> > https://kafka.apache.org/documentation/#security_ssl
> >
> > I have few questions about trust store and keystore based on this
> scenario:
> >
> > We have 5 Kafka Brokers in our cluster. We want our clients to write to
> our
> > Kafka brokers in a secure way. Suppose, we also host a private CA as
> > mentioned in the documentation above, and provide our clients the
> *ca-cert*
> > file, which they add it to their trust store.
> >
> > 1. Do we require our clients to generate their certificate and have it
> > signed by our private CA, and add it to their keystore?
> >
> > 2. When is keystore used by clients, and when is truststore used by
> clients
> > ?
> >
> >
> > Thanks.
> >
> > --
> > R
> >
>



-- 
Raghav

Re: Securing Kafka - Keystore and Truststore question

[Rajini Sivaram]

Raqhav,

1. Clients need a keystore if you are using TLS client authentication. To
enable client authentication, you need to configure ssl.client.auth in
server.properties. This can be set to required|requested|none. If you don't
enable client authentication, any client will be able to connect to your
broker. You could alternatively use SASL for client authentication.
.
2. Client keystore is mandatory if ssl.client.auth=required, optional for
requested and not used for none. The truststore configured on the client is
used to authenticate the server. So you have to provide it unless your
broker is using certificates signed by a trusted authority.

Hope that helps.

Rajini

On Fri, May 12, 2017 at 11:35 AM, Raghav  wrote:

> Hi
>
> I read the documentation here:
> https://kafka.apache.org/documentation/#security_ssl
>
> I have few questions about trust store and keystore based on this scenario:
>
> We have 5 Kafka Brokers in our cluster. We want our clients to write to our
> Kafka brokers in a secure way. Suppose, we also host a private CA as
> mentioned in the documentation above, and provide our clients the *ca-cert*
> file, which they add it to their trust store.
>
> 1. Do we require our clients to generate their certificate and have it
> signed by our private CA, and add it to their keystore?
>
> 2. When is keystore used by clients, and when is truststore used by clients
> ?
>
>
> Thanks.
>
> --
> R
>

Securing Kafka - Keystore and Truststore question

[Raghav]

Hi

I read the documentation here:
https://kafka.apache.org/documentation/#security_ssl

I have few questions about trust store and keystore based on this scenario:

We have 5 Kafka Brokers in our cluster. We want our clients to write to our
Kafka brokers in a secure way. Suppose, we also host a private CA as
mentioned in the documentation above, and provide our clients the *ca-cert*
file, which they add it to their trust store.

1. Do we require our clients to generate their certificate and have it
signed by our private CA, and add it to their keystore?

2. When is keystore used by clients, and when is truststore used by clients
?


Thanks.

-- 
R

reporting the controller error in securing kafka cluster

[张现忠]

 HI,

I'm building a safe Kafka cluster using SASL_PLAINTEXT。 It can create the 
topic, but not producing and consuming data。

The following is an related log :

less controller.log

[2016-03-08 11:43:44,164] INFO [Controller 0]: Controller starting up 
(kafka.controller.KafkaController)

[2016-03-08 11:43:44,218] INFO [Controller 0]: Broker 0 starting become 
controller state transition (kafka.controller.KafkaController)

[2016-03-08 11:43:44,223] INFO [Controller 0]: Controller 0 incremented epoch 
to 1 (kafka.controller.KafkaController)

[2016-03-08 11:43:44,224] DEBUG [Controller 0]: Registering 
IsrChangeNotificationListener (kafka.controller.KafkaController)

[2016-03-08 11:43:44,241] INFO [Controller 0]: Partitions undergoing preferred 
replica election:  (kafka.controller.KafkaController)

[2016-03-08 11:43:44,242] INFO [Controller 0]: Partitions that completed 
preferred replica election:  (kafka.controller.KafkaController)

[2016-03-08 11:43:44,243] INFO [Controller 0]: Resuming preferred replica 
election for partitions:  (kafka.controller.KafkaController)

[2016-03-08 11:43:44,246] INFO [Controller 0]: Partitions being reassigned: 
Map() (kafka.controller.KafkaController)

[2016-03-08 11:43:44,246] INFO [Controller 0]: Partitions already reassigned: 
List() (kafka.controller.KafkaController)

[2016-03-08 11:43:44,248] INFO [Controller 0]: Resuming reassignment of 
partitions: Map() (kafka.controller.KafkaController)

[2016-03-08 11:43:44,257] INFO [Controller 0]: List of topics to be deleted:  
(kafka.controller.KafkaController)

[2016-03-08 11:43:44,258] INFO [Controller 0]: List of topics ineligible for 
deletion:  (kafka.controller.KafkaController)

[2016-03-08 11:43:44,262] INFO [Controller 0]: Currently active brokers in the 
cluster: Set() (kafka.controller.KafkaController)
[2016-03-08 11:43:44,262] INFO [Controller 0]: Currently shutting brokers in 
the cluster: Set() (kafka.controller.KafkaController)
[2016-03-08 11:43:44,263] INFO [Controller 0]: Current list of topics in the 
cluster: Set() (kafka.controller.KafkaController)
[2016-03-08 11:43:44,267] INFO [Replica state machine on controller 0]: Started 
replica state machine with initial state -> Map() 
(kafka.controller.ReplicaStateMachine)
[2016-03-08 11:43:44,273] INFO [Partition state machine on Controller 0]: 
Started partition state machine with initial state -> Map() 
(kafka.controller.PartitionStateMachine)
[2016-03-08 11:43:44,274] INFO [Controller 0]: Broker 0 is ready to serve as 
the new controller with epoch 1 (kafka.controller.KafkaController)
[2016-03-08 11:43:44,276] INFO [Controller 0]: Starting preferred replica 
leader election for partitions  (kafka.controller.KafkaController)
[2016-03-08 11:43:44,277] INFO [Partition state machine on Controller 0]: 
Invoking state change to OnlinePartition for partitions  
(kafka.controller.PartitionStateMachine)
[2016-03-08 11:43:44,283] INFO [Controller 0]: starting the partition rebalance 
scheduler (kafka.controller.KafkaController)
[2016-03-08 11:43:44,284] INFO [Controller 0]: Controller startup complete 
(kafka.controller.KafkaController)
[2016-03-08 11:43:44,422] INFO [BrokerChangeListener on Controller 0]: Broker 
change listener fired for path /brokers/ids with children 0 
(kafka.controller.ReplicaStateMachine$BrokerChangeListener)
[2016-03-08 11:43:44,538] INFO [BrokerChangeListener on Controller 0]: Newly 
added brokers: 0, deleted brokers: , all live brokers: 0 
(kafka.controller.ReplicaStateMachine$BrokerChangeListener)
[2016-03-08 11:43:44,539] DEBUG [Channel manager on controller 0]: Controller 0 
trying to connect to broker 0 (kafka.controller.ControllerChannelManager)
[2016-03-08 11:43:44,555] INFO [Controller-0-to-broker-0-send-thread], Starting 
 (kafka.controller.RequestSendThread)
[2016-03-08 11:43:44,555] INFO [Controller 0]: New broker startup callback for 
0 (kafka.controller.KafkaController)
[2016-03-08 11:43:44,604] WARN [Controller-0-to-broker-0-send-thread], 
Controller 0's connection to broker Node(0, kafka-001.vm  9095) was 
unsuccessful (kafka.controller.RequestSendThread)
java.io.IOException: Connection to Node(0, kafka-001.vm, 9095) failed
at 
kafka.utils.NetworkClientBlockingOps$$anonfun$blockingReady$extension$1.apply(NetworkClientBlockingOps.scala:62)
at 
kafka.utils.NetworkClientBlockingOps$$anonfun$blockingReady$extension$1.apply(NetworkClientBlockingOps.scala:58)
at 
kafka.utils.NetworkClientBlockingOps$$anonfun$kafka$utils$NetworkClientBlockingOps$$pollUntil$extension$2.apply(NetworkClientBlockingOps.scala:106)
at 
kafka.utils.NetworkClientBlockingOps$$anonfun$kafka$utils$NetworkClientBlockingOps$$pollUntil$extension$2.apply(NetworkClientBlockingOps.scala:105)
at 
kafka.utils.NetworkClientBlockingOps$.recurse$1(NetworkClientBlockingOps.scala:129)
at 
kafka.utils.NetworkClientBlockingOps$.kafka$utils$NetworkClientBlockingOps$$pollUntilFound$extension(NetworkClientBlockingOps.scala:139)
   

Re: Securing kafka

[Jason Rosenberg]

I'm definitely interested in this too.


On Fri, Aug 30, 2013 at 6:03 PM, Jay Kreps  wrote:

> Yeah if nobody else does it first linkedin will definitely do kerberos/ssl
> + unix permissions at the topic level soonish. If folks already have a head
> start on the auth piece we would love to have that contribution.
>
>
> On Fri, Aug 30, 2013 at 5:25 AM, Maxime Brugidou
> wrote:
>
> > We would love to see kerberos authentication + some unix-like permission
> > system for topics (where one topic is a file and users/groups have read
> > and/or write access).
> >
> > I guess this is not high-priority but it enables some sort of
> > kafka-as-a-service possibility with multi tenancy. You could integrate a
> > quota system later on...
> > On Aug 30, 2013 5:38 AM, "Rajasekar Elango" 
> > wrote:
> >
> > > No certificates are not per topic. It is for entire broker.
> > >
> > > Thanks,
> > > Raja.
> > >
> > >
> > > On Thu, Aug 29, 2013 at 11:33 PM, Joe Stein 
> wrote:
> > >
> > > > are the certificate stores by topic? very interesting!!! looking
> > forward
> > > to
> > > > trying it out and review it
> > > >
> > > > /***
> > > >  Joe Stein
> > > >  Founder, Principal Consultant
> > > >  Big Data Open Source Security LLC
> > > >  http://www.stealth.ly
> > > >  Twitter: @allthingshadoop 
> > > > /
> > > >
> > > >
> > > > On Thu, Aug 29, 2013 at 11:22 PM, Rajasekar Elango
> > > > wrote:
> > > >
> > > > > We have made changes to kafka code to support certificate based
> > mutual
> > > > SSL
> > > > > authentication. So the clients and broker will exchange trusted
> > > > > certificates for successful communication. This provides both
> > > > > authentication and ssl encryption. Planning to contribute that code
> > > back
> > > > to
> > > > > kafka soon.
> > > > >
> > > > > Thanks,
> > > > > Raja.
> > > > >
> > > > >
> > > > > On Thu, Aug 29, 2013 at 11:16 PM, Joe Stein 
> > > wrote:
> > > > >
> > > > > > One use case I have been discussing recently with a few clients
> is
> > > > > > verifying the digital signature of a message as part of the
> > > acceptance
> > > > > > criteria of it being committed to the log and/or when it is
> > consumed.
> > > > > >
> > > > > > I would be very interested in discussing different scenarios such
> > as
> > > > > Kafka
> > > > > > as a service, privacy at rest as well as authorization and
> > > > authentication
> > > > > > (if required).
> > > > > >
> > > > > > Hit me up
> > > > > >
> > > > > > /***
> > > > > >  Joe Stein
> > > > > >  Founder, Principal Consultant
> > > > > >  Big Data Open Source Security LLC
> > > > > >  http://www.stealth.ly
> > > > > >  Twitter: @allthingshadoop <
> http://www.twitter.com/allthingshadoop
> > >
> > > > > > /
> > > > > >
> > > > > >
> > > > > > On Thu, Aug 29, 2013 at 8:13 PM, Jay Kreps 
> > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > We don't have any application-level security at this time so
> the
> > > > answer
> > > > > > is
> > > > > > > whatever you can do at the network/system level.
> > > > > > >
> > > > > > > -Jay
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Aug 29, 2013 at 10:09 AM, Benjamin Black 
> > wrote:
> > > > > > >
> > > > > > > > IP filters on the hosts.
> > > > > > > > On Aug 29, 2013 10:03 AM, "Calvin Lei" 
> > wrote:
> > > > > > > >
> > > > > > > > > Is there a way to stop a malicious user to connect directly
> > to
> > > a
> > > > > > kafka
> > > > > > > > > broker and send any messages? Could we have the brokers to
> > > > accept a
> > > > > > > > message
> > > > > > > > > to a list of know IPs?
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thanks,
> > > > > Raja.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Raja.
> > >
> >
>

Re: Securing kafka

[Jay Kreps]

Yeah if nobody else does it first linkedin will definitely do kerberos/ssl
+ unix permissions at the topic level soonish. If folks already have a head
start on the auth piece we would love to have that contribution.


On Fri, Aug 30, 2013 at 5:25 AM, Maxime Brugidou
wrote:

> We would love to see kerberos authentication + some unix-like permission
> system for topics (where one topic is a file and users/groups have read
> and/or write access).
>
> I guess this is not high-priority but it enables some sort of
> kafka-as-a-service possibility with multi tenancy. You could integrate a
> quota system later on...
> On Aug 30, 2013 5:38 AM, "Rajasekar Elango" 
> wrote:
>
> > No certificates are not per topic. It is for entire broker.
> >
> > Thanks,
> > Raja.
> >
> >
> > On Thu, Aug 29, 2013 at 11:33 PM, Joe Stein  wrote:
> >
> > > are the certificate stores by topic? very interesting!!! looking
> forward
> > to
> > > trying it out and review it
> > >
> > > /***
> > >  Joe Stein
> > >  Founder, Principal Consultant
> > >  Big Data Open Source Security LLC
> > >  http://www.stealth.ly
> > >  Twitter: @allthingshadoop 
> > > /
> > >
> > >
> > > On Thu, Aug 29, 2013 at 11:22 PM, Rajasekar Elango
> > > wrote:
> > >
> > > > We have made changes to kafka code to support certificate based
> mutual
> > > SSL
> > > > authentication. So the clients and broker will exchange trusted
> > > > certificates for successful communication. This provides both
> > > > authentication and ssl encryption. Planning to contribute that code
> > back
> > > to
> > > > kafka soon.
> > > >
> > > > Thanks,
> > > > Raja.
> > > >
> > > >
> > > > On Thu, Aug 29, 2013 at 11:16 PM, Joe Stein 
> > wrote:
> > > >
> > > > > One use case I have been discussing recently with a few clients is
> > > > > verifying the digital signature of a message as part of the
> > acceptance
> > > > > criteria of it being committed to the log and/or when it is
> consumed.
> > > > >
> > > > > I would be very interested in discussing different scenarios such
> as
> > > > Kafka
> > > > > as a service, privacy at rest as well as authorization and
> > > authentication
> > > > > (if required).
> > > > >
> > > > > Hit me up
> > > > >
> > > > > /***
> > > > >  Joe Stein
> > > > >  Founder, Principal Consultant
> > > > >  Big Data Open Source Security LLC
> > > > >  http://www.stealth.ly
> > > > >  Twitter: @allthingshadoop  >
> > > > > /
> > > > >
> > > > >
> > > > > On Thu, Aug 29, 2013 at 8:13 PM, Jay Kreps 
> > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > We don't have any application-level security at this time so the
> > > answer
> > > > > is
> > > > > > whatever you can do at the network/system level.
> > > > > >
> > > > > > -Jay
> > > > > >
> > > > > >
> > > > > > On Thu, Aug 29, 2013 at 10:09 AM, Benjamin Black 
> wrote:
> > > > > >
> > > > > > > IP filters on the hosts.
> > > > > > > On Aug 29, 2013 10:03 AM, "Calvin Lei" 
> wrote:
> > > > > > >
> > > > > > > > Is there a way to stop a malicious user to connect directly
> to
> > a
> > > > > kafka
> > > > > > > > broker and send any messages? Could we have the brokers to
> > > accept a
> > > > > > > message
> > > > > > > > to a list of know IPs?
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Thanks,
> > > > Raja.
> > > >
> > >
> >
> >
> >
> > --
> > Thanks,
> > Raja.
> >
>

Re: Securing kafka

[Scott Clasen]

Please contribute that back!, Would potentially be huge for mirroring
clusters across Amazon Regions, for instance.


On Thu, Aug 29, 2013 at 8:22 PM, Rajasekar Elango wrote:

> We have made changes to kafka code to support certificate based mutual SSL
> authentication. So the clients and broker will exchange trusted
> certificates for successful communication. This provides both
> authentication and ssl encryption. Planning to contribute that code back to
> kafka soon.
>
> Thanks,
> Raja.
>
>
> On Thu, Aug 29, 2013 at 11:16 PM, Joe Stein  wrote:
>
> > One use case I have been discussing recently with a few clients is
> > verifying the digital signature of a message as part of the acceptance
> > criteria of it being committed to the log and/or when it is consumed.
> >
> > I would be very interested in discussing different scenarios such as
> Kafka
> > as a service, privacy at rest as well as authorization and authentication
> > (if required).
> >
> > Hit me up
> >
> > /***
> >  Joe Stein
> >  Founder, Principal Consultant
> >  Big Data Open Source Security LLC
> >  http://www.stealth.ly
> >  Twitter: @allthingshadoop 
> > /
> >
> >
> > On Thu, Aug 29, 2013 at 8:13 PM, Jay Kreps  wrote:
> >
> > > +1
> > >
> > > We don't have any application-level security at this time so the answer
> > is
> > > whatever you can do at the network/system level.
> > >
> > > -Jay
> > >
> > >
> > > On Thu, Aug 29, 2013 at 10:09 AM, Benjamin Black  wrote:
> > >
> > > > IP filters on the hosts.
> > > > On Aug 29, 2013 10:03 AM, "Calvin Lei"  wrote:
> > > >
> > > > > Is there a way to stop a malicious user to connect directly to a
> > kafka
> > > > > broker and send any messages? Could we have the brokers to accept a
> > > > message
> > > > > to a list of know IPs?
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Thanks,
> Raja.
>

Re: Securing kafka

[Calvin Lei]

That's sounds very interesting. Looking forward to it!
On Aug 29, 2013 11:23 PM, "Rajasekar Elango"  wrote:

> We have made changes to kafka code to support certificate based mutual SSL
> authentication. So the clients and broker will exchange trusted
> certificates for successful communication. This provides both
> authentication and ssl encryption. Planning to contribute that code back to
> kafka soon.
>
> Thanks,
> Raja.
>
>
> On Thu, Aug 29, 2013 at 11:16 PM, Joe Stein  wrote:
>
> > One use case I have been discussing recently with a few clients is
> > verifying the digital signature of a message as part of the acceptance
> > criteria of it being committed to the log and/or when it is consumed.
> >
> > I would be very interested in discussing different scenarios such as
> Kafka
> > as a service, privacy at rest as well as authorization and authentication
> > (if required).
> >
> > Hit me up
> >
> > /***
> >  Joe Stein
> >  Founder, Principal Consultant
> >  Big Data Open Source Security LLC
> >  http://www.stealth.ly
> >  Twitter: @allthingshadoop 
> > /
> >
> >
> > On Thu, Aug 29, 2013 at 8:13 PM, Jay Kreps  wrote:
> >
> > > +1
> > >
> > > We don't have any application-level security at this time so the answer
> > is
> > > whatever you can do at the network/system level.
> > >
> > > -Jay
> > >
> > >
> > > On Thu, Aug 29, 2013 at 10:09 AM, Benjamin Black  wrote:
> > >
> > > > IP filters on the hosts.
> > > > On Aug 29, 2013 10:03 AM, "Calvin Lei"  wrote:
> > > >
> > > > > Is there a way to stop a malicious user to connect directly to a
> > kafka
> > > > > broker and send any messages? Could we have the brokers to accept a
> > > > message
> > > > > to a list of know IPs?
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Thanks,
> Raja.
>

Re: Securing kafka

[Maxime Brugidou]

We would love to see kerberos authentication + some unix-like permission
system for topics (where one topic is a file and users/groups have read
and/or write access).

I guess this is not high-priority but it enables some sort of
kafka-as-a-service possibility with multi tenancy. You could integrate a
quota system later on...
On Aug 30, 2013 5:38 AM, "Rajasekar Elango"  wrote:

> No certificates are not per topic. It is for entire broker.
>
> Thanks,
> Raja.
>
>
> On Thu, Aug 29, 2013 at 11:33 PM, Joe Stein  wrote:
>
> > are the certificate stores by topic? very interesting!!! looking forward
> to
> > trying it out and review it
> >
> > /***
> >  Joe Stein
> >  Founder, Principal Consultant
> >  Big Data Open Source Security LLC
> >  http://www.stealth.ly
> >  Twitter: @allthingshadoop 
> > /
> >
> >
> > On Thu, Aug 29, 2013 at 11:22 PM, Rajasekar Elango
> > wrote:
> >
> > > We have made changes to kafka code to support certificate based mutual
> > SSL
> > > authentication. So the clients and broker will exchange trusted
> > > certificates for successful communication. This provides both
> > > authentication and ssl encryption. Planning to contribute that code
> back
> > to
> > > kafka soon.
> > >
> > > Thanks,
> > > Raja.
> > >
> > >
> > > On Thu, Aug 29, 2013 at 11:16 PM, Joe Stein 
> wrote:
> > >
> > > > One use case I have been discussing recently with a few clients is
> > > > verifying the digital signature of a message as part of the
> acceptance
> > > > criteria of it being committed to the log and/or when it is consumed.
> > > >
> > > > I would be very interested in discussing different scenarios such as
> > > Kafka
> > > > as a service, privacy at rest as well as authorization and
> > authentication
> > > > (if required).
> > > >
> > > > Hit me up
> > > >
> > > > /***
> > > >  Joe Stein
> > > >  Founder, Principal Consultant
> > > >  Big Data Open Source Security LLC
> > > >  http://www.stealth.ly
> > > >  Twitter: @allthingshadoop 
> > > > /
> > > >
> > > >
> > > > On Thu, Aug 29, 2013 at 8:13 PM, Jay Kreps 
> > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > We don't have any application-level security at this time so the
> > answer
> > > > is
> > > > > whatever you can do at the network/system level.
> > > > >
> > > > > -Jay
> > > > >
> > > > >
> > > > > On Thu, Aug 29, 2013 at 10:09 AM, Benjamin Black  wrote:
> > > > >
> > > > > > IP filters on the hosts.
> > > > > > On Aug 29, 2013 10:03 AM, "Calvin Lei"  wrote:
> > > > > >
> > > > > > > Is there a way to stop a malicious user to connect directly to
> a
> > > > kafka
> > > > > > > broker and send any messages? Could we have the brokers to
> > accept a
> > > > > > message
> > > > > > > to a list of know IPs?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Raja.
> > >
> >
>
>
>
> --
> Thanks,
> Raja.
>

Re: Securing kafka

[Rajasekar Elango]

No certificates are not per topic. It is for entire broker.

Thanks,
Raja.


On Thu, Aug 29, 2013 at 11:33 PM, Joe Stein  wrote:

> are the certificate stores by topic? very interesting!!! looking forward to
> trying it out and review it
>
> /***
>  Joe Stein
>  Founder, Principal Consultant
>  Big Data Open Source Security LLC
>  http://www.stealth.ly
>  Twitter: @allthingshadoop 
> /
>
>
> On Thu, Aug 29, 2013 at 11:22 PM, Rajasekar Elango
> wrote:
>
> > We have made changes to kafka code to support certificate based mutual
> SSL
> > authentication. So the clients and broker will exchange trusted
> > certificates for successful communication. This provides both
> > authentication and ssl encryption. Planning to contribute that code back
> to
> > kafka soon.
> >
> > Thanks,
> > Raja.
> >
> >
> > On Thu, Aug 29, 2013 at 11:16 PM, Joe Stein  wrote:
> >
> > > One use case I have been discussing recently with a few clients is
> > > verifying the digital signature of a message as part of the acceptance
> > > criteria of it being committed to the log and/or when it is consumed.
> > >
> > > I would be very interested in discussing different scenarios such as
> > Kafka
> > > as a service, privacy at rest as well as authorization and
> authentication
> > > (if required).
> > >
> > > Hit me up
> > >
> > > /***
> > >  Joe Stein
> > >  Founder, Principal Consultant
> > >  Big Data Open Source Security LLC
> > >  http://www.stealth.ly
> > >  Twitter: @allthingshadoop 
> > > /
> > >
> > >
> > > On Thu, Aug 29, 2013 at 8:13 PM, Jay Kreps 
> wrote:
> > >
> > > > +1
> > > >
> > > > We don't have any application-level security at this time so the
> answer
> > > is
> > > > whatever you can do at the network/system level.
> > > >
> > > > -Jay
> > > >
> > > >
> > > > On Thu, Aug 29, 2013 at 10:09 AM, Benjamin Black  wrote:
> > > >
> > > > > IP filters on the hosts.
> > > > > On Aug 29, 2013 10:03 AM, "Calvin Lei"  wrote:
> > > > >
> > > > > > Is there a way to stop a malicious user to connect directly to a
> > > kafka
> > > > > > broker and send any messages? Could we have the brokers to
> accept a
> > > > > message
> > > > > > to a list of know IPs?
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Thanks,
> > Raja.
> >
>



-- 
Thanks,
Raja.

Re: Securing kafka

[Joe Stein]

are the certificate stores by topic? very interesting!!! looking forward to
trying it out and review it

/***
 Joe Stein
 Founder, Principal Consultant
 Big Data Open Source Security LLC
 http://www.stealth.ly
 Twitter: @allthingshadoop 
/


On Thu, Aug 29, 2013 at 11:22 PM, Rajasekar Elango
wrote:

> We have made changes to kafka code to support certificate based mutual SSL
> authentication. So the clients and broker will exchange trusted
> certificates for successful communication. This provides both
> authentication and ssl encryption. Planning to contribute that code back to
> kafka soon.
>
> Thanks,
> Raja.
>
>
> On Thu, Aug 29, 2013 at 11:16 PM, Joe Stein  wrote:
>
> > One use case I have been discussing recently with a few clients is
> > verifying the digital signature of a message as part of the acceptance
> > criteria of it being committed to the log and/or when it is consumed.
> >
> > I would be very interested in discussing different scenarios such as
> Kafka
> > as a service, privacy at rest as well as authorization and authentication
> > (if required).
> >
> > Hit me up
> >
> > /***
> >  Joe Stein
> >  Founder, Principal Consultant
> >  Big Data Open Source Security LLC
> >  http://www.stealth.ly
> >  Twitter: @allthingshadoop 
> > /
> >
> >
> > On Thu, Aug 29, 2013 at 8:13 PM, Jay Kreps  wrote:
> >
> > > +1
> > >
> > > We don't have any application-level security at this time so the answer
> > is
> > > whatever you can do at the network/system level.
> > >
> > > -Jay
> > >
> > >
> > > On Thu, Aug 29, 2013 at 10:09 AM, Benjamin Black  wrote:
> > >
> > > > IP filters on the hosts.
> > > > On Aug 29, 2013 10:03 AM, "Calvin Lei"  wrote:
> > > >
> > > > > Is there a way to stop a malicious user to connect directly to a
> > kafka
> > > > > broker and send any messages? Could we have the brokers to accept a
> > > > message
> > > > > to a list of know IPs?
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Thanks,
> Raja.
>

Re: Securing kafka

[Rajasekar Elango]

We have made changes to kafka code to support certificate based mutual SSL
authentication. So the clients and broker will exchange trusted
certificates for successful communication. This provides both
authentication and ssl encryption. Planning to contribute that code back to
kafka soon.

Thanks,
Raja.


On Thu, Aug 29, 2013 at 11:16 PM, Joe Stein  wrote:

> One use case I have been discussing recently with a few clients is
> verifying the digital signature of a message as part of the acceptance
> criteria of it being committed to the log and/or when it is consumed.
>
> I would be very interested in discussing different scenarios such as Kafka
> as a service, privacy at rest as well as authorization and authentication
> (if required).
>
> Hit me up
>
> /***
>  Joe Stein
>  Founder, Principal Consultant
>  Big Data Open Source Security LLC
>  http://www.stealth.ly
>  Twitter: @allthingshadoop 
> /
>
>
> On Thu, Aug 29, 2013 at 8:13 PM, Jay Kreps  wrote:
>
> > +1
> >
> > We don't have any application-level security at this time so the answer
> is
> > whatever you can do at the network/system level.
> >
> > -Jay
> >
> >
> > On Thu, Aug 29, 2013 at 10:09 AM, Benjamin Black  wrote:
> >
> > > IP filters on the hosts.
> > > On Aug 29, 2013 10:03 AM, "Calvin Lei"  wrote:
> > >
> > > > Is there a way to stop a malicious user to connect directly to a
> kafka
> > > > broker and send any messages? Could we have the brokers to accept a
> > > message
> > > > to a list of know IPs?
> > > >
> > >
> >
>



-- 
Thanks,
Raja.

Re: Securing kafka

[Joe Stein]

One use case I have been discussing recently with a few clients is
verifying the digital signature of a message as part of the acceptance
criteria of it being committed to the log and/or when it is consumed.

I would be very interested in discussing different scenarios such as Kafka
as a service, privacy at rest as well as authorization and authentication
(if required).

Hit me up

/***
 Joe Stein
 Founder, Principal Consultant
 Big Data Open Source Security LLC
 http://www.stealth.ly
 Twitter: @allthingshadoop 
/


On Thu, Aug 29, 2013 at 8:13 PM, Jay Kreps  wrote:

> +1
>
> We don't have any application-level security at this time so the answer is
> whatever you can do at the network/system level.
>
> -Jay
>
>
> On Thu, Aug 29, 2013 at 10:09 AM, Benjamin Black  wrote:
>
> > IP filters on the hosts.
> > On Aug 29, 2013 10:03 AM, "Calvin Lei"  wrote:
> >
> > > Is there a way to stop a malicious user to connect directly to a kafka
> > > broker and send any messages? Could we have the brokers to accept a
> > message
> > > to a list of know IPs?
> > >
> >
>

Re: Securing kafka

[Jay Kreps]

+1

We don't have any application-level security at this time so the answer is
whatever you can do at the network/system level.

-Jay


On Thu, Aug 29, 2013 at 10:09 AM, Benjamin Black  wrote:

> IP filters on the hosts.
> On Aug 29, 2013 10:03 AM, "Calvin Lei"  wrote:
>
> > Is there a way to stop a malicious user to connect directly to a kafka
> > broker and send any messages? Could we have the brokers to accept a
> message
> > to a list of know IPs?
> >
>

RE: Securing kafka

[Sybrandy, Casey]

Another possible solution is to use stunnel to authenticate clients with a 
certificate.  It's a bit harder to spoof a certificate than an IP address.

-Original Message-
From: Benjamin Black [mailto:b...@b3k.us] 
Sent: Thursday, August 29, 2013 1:10 PM
To: users@kafka.apache.org
Subject: Re: Securing kafka

IP filters on the hosts.
On Aug 29, 2013 10:03 AM, "Calvin Lei"  wrote:

> Is there a way to stop a malicious user to connect directly to a kafka 
> broker and send any messages? Could we have the brokers to accept a 
> message to a list of know IPs?
>

Re: Securing kafka

[Benjamin Black]

IP filters on the hosts.
On Aug 29, 2013 10:03 AM, "Calvin Lei"  wrote:

> Is there a way to stop a malicious user to connect directly to a kafka
> broker and send any messages? Could we have the brokers to accept a message
> to a list of know IPs?
>

Securing kafka

[Calvin Lei]

Is there a way to stop a malicious user to connect directly to a kafka
broker and send any messages? Could we have the brokers to accept a message
to a list of know IPs?

Re: Securing Kafka

[Fergal Somers]

Yes securing the content of log messages at rest is important to us - which
favors message encryption.
Thanks for the responses.

Fergal.


On Tue, Apr 23, 2013 at 7:31 PM, Chris Curtin wrote:

> Also keep in mind that anything done at the transport (SSL for example)
> layer won't solve your 'at rest' problems.
>
> All messages are written to disk, so unless the broker does some encryption
> logic you haven't solved the data visibility issues.
>
> I also think this should be a producer/consumer problem not a Broker. Keep
> the Brokers as fast as possible (thus NIO/kernel space activities etc.) and
> push the cost to the producers and consumers.
>
> Chris
>
>
> On Tue, Apr 23, 2013 at 2:02 PM, Jason Rosenberg  wrote:
>
> > Yes,
> >
> > I think encryption at the message level is a workable solution, as long
> as
> > you don't care about exposing the meta data that goes with it (e.g. topic
> > names, kafka broker/zk server locations, etc.).
> >
> > Jason
> >
> >
> > On Tue, Apr 23, 2013 at 10:02 AM, Fergal Somers
> > wrote:
> >
> > > Hi
> > >
> > > We are planning to use Kafka, but like others on this list we have a
> need
> > > to be able to secure communication. The approaches people have
> suggested
> > on
> > > this list are:
> > >
> > >- Encrypt the messages at the producer (e.g
> > >
> > >
> >
> http://search-hadoop.com/m/1AfXKcZIk52/message+encryption&subj=Re+Secure+communication
> > >)
> > >- Add SSL to Kafka protocol -
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/kafka-users/201304.mbox/ajax/%3CCAA%2BBczQ_dMXUTNndSu4d%2B6aRo%3DSLiFa4iGMu_78OWKub_CTScw%40mail.gmail.com%3E
> > >
> > > Adding SSL support to Kafka, probably means adding SSLEngine support
> the
> > > the nio socket handling (
> > >
> https://groups.google.com/forum/#!msg/kafka-dev/ZmJrB_plu1I/_9cmGlLCSVEJ
> > ).
> > > I don't think there are any immediate plans to provide this, but it's
> > > potentially something that Kafka would support in the future?
> > >
> > > In theory this is something we could look at, but we would need to go
> > > further. We also need to separate producers from consumers. The aim
> would
> > > be to ensure that a Kafka producer couldn't also act as a consumer.
> > > Essentially producers can write to Kafka, but not read.
> > >
> > > From looking at the Kafka source, achieving producer/consumer
> separation
> > > looks to me like it would be quite a change to the Kafka server (0.7).
> So
> > > are there any plans in the (near) future in this area (producer /
> > consumer
> > > separation) ?
> > >
> > > Message encryption (at the application layer) would allow us to achieve
> > > both aims of securing communication and separating consumers from
> > > producers. Producers get the public cert (so they can encrypt messages
> as
> > > they place them on the bus). Only consumers get the private cert - so
> > only
> > > they can decrypt messages consumed. This seems like something we can do
> > > ourselves - I just wanted to sanity check the approach with this group.
> > >
> > > Cheers,
> > >
> > > Fergal.
> > >
> >
>



-- 
Fergal Somers
Architect Integrations
(Skype) fergal.somers.workday
fergal.som...@workday.com

Re: Securing Kafka

[Chris Curtin]

Also keep in mind that anything done at the transport (SSL for example)
layer won't solve your 'at rest' problems.

All messages are written to disk, so unless the broker does some encryption
logic you haven't solved the data visibility issues.

I also think this should be a producer/consumer problem not a Broker. Keep
the Brokers as fast as possible (thus NIO/kernel space activities etc.) and
push the cost to the producers and consumers.

Chris


On Tue, Apr 23, 2013 at 2:02 PM, Jason Rosenberg  wrote:

> Yes,
>
> I think encryption at the message level is a workable solution, as long as
> you don't care about exposing the meta data that goes with it (e.g. topic
> names, kafka broker/zk server locations, etc.).
>
> Jason
>
>
> On Tue, Apr 23, 2013 at 10:02 AM, Fergal Somers
> wrote:
>
> > Hi
> >
> > We are planning to use Kafka, but like others on this list we have a need
> > to be able to secure communication. The approaches people have suggested
> on
> > this list are:
> >
> >- Encrypt the messages at the producer (e.g
> >
> >
> http://search-hadoop.com/m/1AfXKcZIk52/message+encryption&subj=Re+Secure+communication
> >)
> >- Add SSL to Kafka protocol -
> >
> >
> http://mail-archives.apache.org/mod_mbox/kafka-users/201304.mbox/ajax/%3CCAA%2BBczQ_dMXUTNndSu4d%2B6aRo%3DSLiFa4iGMu_78OWKub_CTScw%40mail.gmail.com%3E
> >
> > Adding SSL support to Kafka, probably means adding SSLEngine support the
> > the nio socket handling (
> > https://groups.google.com/forum/#!msg/kafka-dev/ZmJrB_plu1I/_9cmGlLCSVEJ
> ).
> > I don't think there are any immediate plans to provide this, but it's
> > potentially something that Kafka would support in the future?
> >
> > In theory this is something we could look at, but we would need to go
> > further. We also need to separate producers from consumers. The aim would
> > be to ensure that a Kafka producer couldn't also act as a consumer.
> > Essentially producers can write to Kafka, but not read.
> >
> > From looking at the Kafka source, achieving producer/consumer separation
> > looks to me like it would be quite a change to the Kafka server (0.7). So
> > are there any plans in the (near) future in this area (producer /
> consumer
> > separation) ?
> >
> > Message encryption (at the application layer) would allow us to achieve
> > both aims of securing communication and separating consumers from
> > producers. Producers get the public cert (so they can encrypt messages as
> > they place them on the bus). Only consumers get the private cert - so
> only
> > they can decrypt messages consumed. This seems like something we can do
> > ourselves - I just wanted to sanity check the approach with this group.
> >
> > Cheers,
> >
> > Fergal.
> >
>

Re: Securing Kafka

[Matt Wise]

The other issue with this model is that you're Kafka servers are available on 
the internet ... so anyone else can push data into them. At least, if you are 
running in a cross-cloud/cross-datacenter environment. We're struggling with 
the same design issues right now.

What we've hoped for is that in 0.8.x, Kafka would allow our producers to 
connect to ANY Kafka server and submit data, and have that data dynamically 
routed to the right servers. This way we could put the Kafka servers behind an 
ELB, throw up Stunnel clients on our producers and Stunnel servers on the Kafka 
machines. This would offload the SSL encryption and authentication to Stunnel, 
and allow Kafka to concentrate on what its good at.

For now though, that doesn't seem possible. It looks like we may end up going 
down the Flume route, because its easier to encrypt and authenticate the data 
streams through Flume. :/

--Matt

On Apr 23, 2013, at 11:02 AM, Jason Rosenberg  wrote:

> Yes,
> 
> I think encryption at the message level is a workable solution, as long as
> you don't care about exposing the meta data that goes with it (e.g. topic
> names, kafka broker/zk server locations, etc.).
> 
> Jason
> 
> 
> On Tue, Apr 23, 2013 at 10:02 AM, Fergal Somers
> wrote:
> 
>> Hi
>> 
>> We are planning to use Kafka, but like others on this list we have a need
>> to be able to secure communication. The approaches people have suggested on
>> this list are:
>> 
>>   - Encrypt the messages at the producer (e.g
>> 
>> http://search-hadoop.com/m/1AfXKcZIk52/message+encryption&subj=Re+Secure+communication
>>   )
>>   - Add SSL to Kafka protocol -
>> 
>> http://mail-archives.apache.org/mod_mbox/kafka-users/201304.mbox/ajax/%3CCAA%2BBczQ_dMXUTNndSu4d%2B6aRo%3DSLiFa4iGMu_78OWKub_CTScw%40mail.gmail.com%3E
>> 
>> Adding SSL support to Kafka, probably means adding SSLEngine support the
>> the nio socket handling (
>> https://groups.google.com/forum/#!msg/kafka-dev/ZmJrB_plu1I/_9cmGlLCSVEJ).
>> I don't think there are any immediate plans to provide this, but it's
>> potentially something that Kafka would support in the future?
>> 
>> In theory this is something we could look at, but we would need to go
>> further. We also need to separate producers from consumers. The aim would
>> be to ensure that a Kafka producer couldn't also act as a consumer.
>> Essentially producers can write to Kafka, but not read.
>> 
>> From looking at the Kafka source, achieving producer/consumer separation
>> looks to me like it would be quite a change to the Kafka server (0.7). So
>> are there any plans in the (near) future in this area (producer / consumer
>> separation) ?
>> 
>> Message encryption (at the application layer) would allow us to achieve
>> both aims of securing communication and separating consumers from
>> producers. Producers get the public cert (so they can encrypt messages as
>> they place them on the bus). Only consumers get the private cert - so only
>> they can decrypt messages consumed. This seems like something we can do
>> ourselves - I just wanted to sanity check the approach with this group.
>> 
>> Cheers,
>> 
>> Fergal.
>> 

Re: Securing Kafka

[Jason Rosenberg]

Yes,

I think encryption at the message level is a workable solution, as long as
you don't care about exposing the meta data that goes with it (e.g. topic
names, kafka broker/zk server locations, etc.).

Jason


On Tue, Apr 23, 2013 at 10:02 AM, Fergal Somers
wrote:

> Hi
>
> We are planning to use Kafka, but like others on this list we have a need
> to be able to secure communication. The approaches people have suggested on
> this list are:
>
>- Encrypt the messages at the producer (e.g
>
> http://search-hadoop.com/m/1AfXKcZIk52/message+encryption&subj=Re+Secure+communication
>)
>- Add SSL to Kafka protocol -
>
> http://mail-archives.apache.org/mod_mbox/kafka-users/201304.mbox/ajax/%3CCAA%2BBczQ_dMXUTNndSu4d%2B6aRo%3DSLiFa4iGMu_78OWKub_CTScw%40mail.gmail.com%3E
>
> Adding SSL support to Kafka, probably means adding SSLEngine support the
> the nio socket handling (
> https://groups.google.com/forum/#!msg/kafka-dev/ZmJrB_plu1I/_9cmGlLCSVEJ).
> I don't think there are any immediate plans to provide this, but it's
> potentially something that Kafka would support in the future?
>
> In theory this is something we could look at, but we would need to go
> further. We also need to separate producers from consumers. The aim would
> be to ensure that a Kafka producer couldn't also act as a consumer.
> Essentially producers can write to Kafka, but not read.
>
> From looking at the Kafka source, achieving producer/consumer separation
> looks to me like it would be quite a change to the Kafka server (0.7). So
> are there any plans in the (near) future in this area (producer / consumer
> separation) ?
>
> Message encryption (at the application layer) would allow us to achieve
> both aims of securing communication and separating consumers from
> producers. Producers get the public cert (so they can encrypt messages as
> they place them on the bus). Only consumers get the private cert - so only
> they can decrypt messages consumed. This seems like something we can do
> ourselves - I just wanted to sanity check the approach with this group.
>
> Cheers,
>
> Fergal.
>

Securing Kafka

[Fergal Somers]

Hi

We are planning to use Kafka, but like others on this list we have a need
to be able to secure communication. The approaches people have suggested on
this list are:

   - Encrypt the messages at the producer (e.g
   
http://search-hadoop.com/m/1AfXKcZIk52/message+encryption&subj=Re+Secure+communication
   )
   - Add SSL to Kafka protocol -
   
http://mail-archives.apache.org/mod_mbox/kafka-users/201304.mbox/ajax/%3CCAA%2BBczQ_dMXUTNndSu4d%2B6aRo%3DSLiFa4iGMu_78OWKub_CTScw%40mail.gmail.com%3E

Adding SSL support to Kafka, probably means adding SSLEngine support the
the nio socket handling (
https://groups.google.com/forum/#!msg/kafka-dev/ZmJrB_plu1I/_9cmGlLCSVEJ).
I don't think there are any immediate plans to provide this, but it's
potentially something that Kafka would support in the future?

In theory this is something we could look at, but we would need to go
further. We also need to separate producers from consumers. The aim would
be to ensure that a Kafka producer couldn't also act as a consumer.
Essentially producers can write to Kafka, but not read.

>From looking at the Kafka source, achieving producer/consumer separation
looks to me like it would be quite a change to the Kafka server (0.7). So
are there any plans in the (near) future in this area (producer / consumer
separation) ?

Message encryption (at the application layer) would allow us to achieve
both aims of securing communication and separating consumers from
producers. Producers get the public cert (so they can encrypt messages as
they place them on the bus). Only consumers get the private cert - so only
they can decrypt messages consumed. This seems like something we can do
ourselves - I just wanted to sanity check the approach with this group.

Cheers,

Fergal.