[jira] [Comment Edited] (KAFKA-1810) Add IP Filtering / Whitelists-Blacklists
[ https://issues.apache.org/jira/browse/KAFKA-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240484#comment-14240484 ] Jeff Holoman edited comment on KAFKA-1810 at 12/14/14 3:08 PM: --- [~bosco] , I did note the broader security-related JIRA and have been following it somewhat closely. I'm keenly interested in this topic generally. I think this proposal makes sense for a number of reasons 1) While this feature is certainly related to security its intent is really more to insulate against configuration issues and give software administrators the ability manage incoming connections by network range. For example, make sure my QA isn't writing to Prod. 2) This is a relatively simple change that doesn't require dependencies on a much larger security initiative. 3) There's no reason why this feature couldn't be worked into the upcoming permissions manager. 4) The configuration is very minor, a list / range of IP addresses to allow/deny Essentially this would cover the following scenarios 1) Allow any incoming connections but deny certain IP blocks 2) The inverse of the above 3) Some combination of the two, where certain subnets were allowed/denied, e.g. allow all traffic from 192.168.2.0/12 but deny 192.168.2.0/28. This concept is probably most related to IPTables or AWS security groups… What I mean here, we have other more sophisticated methods of authorizing access in other systems but the ability to filter simple network requests from a given IP range I think provides a valuable tool in the administrator's kit. As such I think this would provide this particular capability to restrict access in the near term until a more robust implementation is completed, or in conjunction with that initiative. As far as I know, the rollout for 1688 is TBD. was (Author: jholoman): [~bosco] , I did note the broader security-related JIRA and have been following it somewhat closely. I'm keenly interested in this topic generally. I think this proposal makes sense for a number of reasons 1) While this feature is certainly related to security it's intent is really more to insulate against configuration issues and give software administrators the ability manage incoming connections by network range. For example, make sure my QA isn't writing to Prod. 2) This is a relatively simple change that doesn't require dependencies on a much larger security initiative. 3) There's no reason why this feature couldn't be worked into the upcoming permissions manager. 4) The configuration is very minor, a list / range of IP addresses to allow/deny Essentially this would cover the following scenarios 1) Allow any incoming connections but deny certain IP blocks 2) The inverse of the above 3) Some combination of the two, where certain subnets were allowed/denied, e.g. allow all traffic from 192.168.2.0/12 but deny 192.168.2.0/28. This concept is probably most related to IPTables or AWS security groups… What I mean here, we have other more sophisticated methods of authorizing access in other systems but the ability to filter simple network requests from a given IP range I think provides a valuable tool in the administrator's kit. As such I think this would provide this particular capability to restrict access in the near term until a more robust implementation is completed, or in conjunction with that initiative. As far as I know, the rollout for 1688 is TBD. 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 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] [Comment Edited] (KAFKA-1810) Add IP Filtering / Whitelists-Blacklists
[ https://issues.apache.org/jira/browse/KAFKA-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240484#comment-14240484 ] Jeff Holoman edited comment on KAFKA-1810 at 12/10/14 1:38 AM: --- [~bosco] , I did note the broader security-related JIRA and have been following it somewhat closely. I'm keenly interested in this topic generally. I think this proposal makes sense for a number of reasons 1) While this feature is certainly related to security it's intent is really more to insulate against configuration issues and give software administrators the ability manage incoming connections by network range. For example, make sure my QA isn't writing to Prod. 2) This is a relatively simple change that doesn't require dependencies on a much larger security initiative. 3) There's no reason why this feature couldn't be worked into the upcoming permissions manager. 4) The configuration is very minor, a list / range of IP addresses to allow/deny Essentially this would cover the following scenarios 1) Allow any incoming connections but deny certain IP blocks 2) The inverse of the above 3) Some combination of the two, where certain subnets were allowed/denied, e.g. allow all traffic from 192.168.2.0/12 but deny 192.168.2.0/28. This concept is probably most related to IPTables or AWS security groups… What I mean here, we have other more sophisticated methods of authorizing access in other systems but the ability to filter simple network requests from a given IP range I think provides a valuable tool in the administrator's kit. As such I think this would provide this particular capability to restrict access in the near term until a more robust implementation is completed, or in conjunction with that initiative. As far as I know, the rollout for 1688 is TBD. was (Author: jholoman): [~bosco] I did note the broader security-related JIRA and have been following it somewhat closely. I'm keenly interested in this topic generally. I think this proposal makes sense for a number of reasons 1) While this feature is certainly related to security it's intent is really more to insulate against configuration issues and give software administrators the ability manage incoming connections by network range. For example, make sure my QA isn't writing to Prod. 2) This is a relatively simple change that doesn't require dependencies on a much larger security initiative. 3) There's no reason why this feature couldn't be worked into the upcoming permissions manager. 4) The configuration is very minor, a list / range of IP addresses to allow/deny Essentially this would cover the following scenarios 1) Allow any incoming connections but deny certain IP blocks 2) The inverse of the above 3) Some combination of the two, where certain subnets were allowed/denied, e.g. allow all traffic from 192.168.2.0/12 but deny 192.168.2.0/28. This concept is probably most related to IPTables or AWS security groups… What I mean here, we have other more sophisticated methods of authorizing access in other systems but the ability to filter simple network requests from a given IP range I think provides a valuable tool in the administrator's kit. As such I think this would provide this particular capability to restrict access in the near term until a more robust implementation is completed, or in conjunction with that initiative. As far as I know, the rollout for 1688 is TBD. 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 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
