[ https://issues.apache.org/jira/browse/KAFKA-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14269579#comment-14269579 ]
Jeff Holoman commented on KAFKA-1810: ------------------------------------- This patch is a first pass at implementing IP Filtering logic. It requires defining two additional properties: security.ip.filter.rule.type security.ip.filter.list. The list of IP's are specified in CIDR notation: http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing. This implementation supports whitelisting ("allow" config value) or blacklisting ("deny"), mutually exclusive. The parameters are passed to socket server and validated upon startup.(I'd like to move most of the validation logic per KAFKA-1845). An exception is thrown and the server shutdown in the event of misconfiguration of these parameters. The check against the list is in the Acceptor thread, and if the rule check fails, the socket is closed. There are a lot of tests included in the patch but if there are suggestions for more please let me know. > Add IP Filtering / Whitelists-Blacklists > ----------------------------------------- > > Key: KAFKA-1810 > URL: https://issues.apache.org/jira/browse/KAFKA-1810 > Project: Kafka > Issue Type: New Feature > Components: core, network > Reporter: Jeff Holoman > Assignee: Jeff Holoman > Priority: Minor > Fix For: 0.8.3 > > Attachments: KAFKA-1810.patch > > > While longer-term goals of security in Kafka are on the roadmap there exists > some value for the ability to restrict connection to Kafka brokers based on > IP address. This is not intended as a replacement for security but more of a > precaution against misconfiguration and to provide some level of control to > Kafka administrators about who is reading/writing to their cluster. > 1) In some organizations software administration vs o/s systems > administration and network administration is disjointed and not well > choreographed. Providing software administrators the ability to configure > their platform relatively independently (after initial configuration) from > Systems administrators is desirable. > 2) Configuration and deployment is sometimes error prone and there are > situations when test environments could erroneously read/write to production > environments > 3) An additional precaution against reading sensitive data is typically > welcomed in most large enterprise deployments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
