Hi Ismael,
Thanks for clarifying this with the example.
I tried it and it worked as you have described below !
I have a follow up question:
Producer (PR) and Consumer (CO) are running on two different Clients and
talking to broker (BR)
Goal: Multiple Principals (P1 .. Pn) should be able to access PR in order to
write/read to some topics (T1 .. Tn).
I have a mapping like Px -> Tx.
For example:
Principal P1 has “Write” permission on topics T1, T2
Principal P2 has “Write” permission on topics T2, T9
If I do kafka-acls --list, it should look like:
Current ACLs for resource `Topic:T1`:
User:P1 has Allow permission for operations: Write from hosts: *
Current ACLs for resource `Topic:T2:
User:P1 has Allow permission for operations: Write from hosts: *
User:P2 has Allow permission for operations: Write from hosts: *
Current ACLs for resource `Topic:T9:
User:P2 has Allow permission for operations: Write from hosts: *
How should I build such topic level access control per principal.
Option 1: One Certificate per Principal
* Truststore of a client stores all the certificates corresponding to each
Principal
* But, how will the producer client dynamically pick a certificate based on the
principal.
Option 2: One Kerberos user per Principal
* In long-running process (useKeyTab=true and not useTicketCache=true), the
keyTab and principal is very specific to one user (Principal).
* How to make this more dynamic to support users getting authenticated over a
REST API ?
If you have any examples or pointers that would be great.
Thanks,
—
Gopal
On 3/21/16, 7:54 PM, "isma...@gmail.com on behalf of Ismael Juma"
<isma...@gmail.com on behalf of ism...@juma.me.uk> wrote:
>Hi Gopal,
>
>As you suspected, you have to set the appropriate ACLs for it to work. The
>following will make the producer work:
>
>kafka-acls --authorizer-properties zookeeper.connect=localhost:2181 \
>--add --allow-principal
>"User:CN=kafka.example.com,OU=Client,O=Confluent,L=London,ST=London,C=GB"
>\
>--producer --topic securing-kafka
>
>The following will make the consumer work:
>
>kafka-acls --authorizer-properties zookeeper.connect=localhost:2181 \
>--add --allow-principal
>"User:CN=kafka.example.com,OU=Client,O=Confluent,L=London,ST=London,C=GB"
>\
>--consumer --topic securing-kafka --group securing-kafka-group
>
>Enabling the authorizer log is a good way to figure out the principal if
>you don't know it.
>
>Hope this helps,
>Ismael
>
>On Mon, Mar 21, 2016 at 10:27 PM, Raghavan, Gopal <gopal.ragha...@here.com>
>wrote:
>
>> >Hi Christopher,
>>
>> >On Mon, Mar 21, 2016 at 3:53 PM, christopher palm <cpa...@gmail.com>
>> wrote:
>>
>> >> Does Kafka support SSL authentication and ACL authorization without
>> >> Kerberos?
>> >>
>>
>> >Yes. The following branch modifies the blog example slightly to only allow
>> >SSL authentication.
>>
>> >https://github.com/confluentinc/securing-kafka-blog/tree/ssl-only
>>
>> >If so, can different clients have their own SSL certificate on the same
>> >> broker?
>> >>
>>
>> >Yes.
>>
>>
>>
>> I tried the “ssl-only” branch but am getting the following error:
>>
>> [vagrant@kafka ~]$ kafka-console-producer --broker-list
>> kafka.example.com:9093 --topic securing-kafka --producer.config
>> /etc/kafka/producer_ssl.properties
>>
>>
>>
>>
>> test
>>
>>
>>
>>
>> [2016-03-21 22:08:46,744] WARN Error while fetching metadata with
>> correlation id 0 : {securing-kafka=TOPIC_AUTHORIZATION_FAILED}
>> (org.apache.kafka.clients.NetworkClient)
>>
>>
>>
>>
>> [2016-03-21 22:08:46,748] ERROR Error when sending message to topic
>> securing-kafka with key: null, value: 4 bytes with error: Not authorized to
>> access topics: [securing-kafka]
>> (org.apache.kafka.clients.producer.internals.ErrorLoggingCallback)
>>
>>
>>
>>
>> I did not set topic level ACL, since I do not know the Principal name to
>> use for --allow-principal parameter of kafka-acls
>>
>>
>> Any suggestions ?
>>
>>
>> >In reading the following security article, it seems that Kerberos is an
>> >> option but not required if SSL is used.
>> >>
>>
>> >That's right.
>>
>> >Ismael
>>
