[jira] [Commented] (KAFKA-1688) Add authorization interface and naive implementation
[ https://issues.apache.org/jira/browse/KAFKA-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14378100#comment-14378100 ] Don Bosco Durai commented on KAFKA-1688: [~prasadm], I agree with you, we should support ALL or equivalent keyword like (*) in the default implementation. I remember the Hierarchical subject brought up during one the google hangout discussion around authorization. I don't think there were any resolutions around it. Does it make sense to make this as a custom implementation feature? So for OOTB, it would be be just topic name, but anyone who want to implement hierarchical privileges can parse the topic name and use . or any other supported character has delimiter and provide namespace/database like permissions. FYI, it seems, hierarchical Topics was discussed back in 2012 https://cwiki.apache.org/confluence/display/KAFKA/Hierarchical+Topics Add authorization interface and naive implementation Key: KAFKA-1688 URL: https://issues.apache.org/jira/browse/KAFKA-1688 Project: Kafka Issue Type: Sub-task Components: security Reporter: Jay Kreps Assignee: Parth Brahmbhatt Fix For: 0.8.3 Add a PermissionManager interface as described here: https://cwiki.apache.org/confluence/display/KAFKA/Security (possibly there is a better name?) Implement calls to the PermissionsManager in KafkaApis for the main requests (FetchRequest, ProduceRequest, etc). We will need to add a new error code and exception to the protocol to indicate permission denied. Add a server configuration to give the class you want to instantiate that implements that interface. That class can define its own configuration properties from the main config file. Provide a simple implementation of this interface which just takes a user and ip whitelist and permits those in either of the whitelists to do anything, and denies all others. Rather than writing an integration test for this class we can probably just use this class for the TLS and SASL authentication testing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1688) Add authorization interface and naive implementation
[ https://issues.apache.org/jira/browse/KAFKA-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14283104#comment-14283104 ] Don Bosco Durai commented on KAFKA-1688: [~charmalloc], can you help me create a new Wiki page to put the high level design for this feature? It will be easier to discuss based on that. Thanks Add authorization interface and naive implementation Key: KAFKA-1688 URL: https://issues.apache.org/jira/browse/KAFKA-1688 Project: Kafka Issue Type: Sub-task Components: security Reporter: Jay Kreps Assignee: Sriharsha Chintalapani Fix For: 0.8.3 Add a PermissionManager interface as described here: https://cwiki.apache.org/confluence/display/KAFKA/Security (possibly there is a better name?) Implement calls to the PermissionsManager in KafkaApis for the main requests (FetchRequest, ProduceRequest, etc). We will need to add a new error code and exception to the protocol to indicate permission denied. Add a server configuration to give the class you want to instantiate that implements that interface. That class can define its own configuration properties from the main config file. Provide a simple implementation of this interface which just takes a user and ip whitelist and permits those in either of the whitelists to do anything, and denies all others. Rather than writing an integration test for this class we can probably just use this class for the TLS and SASL authentication testing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1688) Add authorization interface and naive implementation
[ https://issues.apache.org/jira/browse/KAFKA-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14283155#comment-14283155 ] Don Bosco Durai commented on KAFKA-1688: My id is bosco. I think I might already have write access to the Wiki. It would be good if you can create a new page where I can start putting content, which can be linked from the requirement document https://cwiki.apache.org/confluence/display/KAFKA/Security. If there is already a design page for security, then I can use that also. Thanks Add authorization interface and naive implementation Key: KAFKA-1688 URL: https://issues.apache.org/jira/browse/KAFKA-1688 Project: Kafka Issue Type: Sub-task Components: security Reporter: Jay Kreps Assignee: Sriharsha Chintalapani Fix For: 0.8.3 Add a PermissionManager interface as described here: https://cwiki.apache.org/confluence/display/KAFKA/Security (possibly there is a better name?) Implement calls to the PermissionsManager in KafkaApis for the main requests (FetchRequest, ProduceRequest, etc). We will need to add a new error code and exception to the protocol to indicate permission denied. Add a server configuration to give the class you want to instantiate that implements that interface. That class can define its own configuration properties from the main config file. Provide a simple implementation of this interface which just takes a user and ip whitelist and permits those in either of the whitelists to do anything, and denies all others. Rather than writing an integration test for this class we can probably just use this class for the TLS and SASL authentication testing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1722) static analysis code coverage for pci audit needs
[ https://issues.apache.org/jira/browse/KAFKA-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14282002#comment-14282002 ] Don Bosco Durai commented on KAFKA-1722: There few things to note here: - Instrumentation and scanning takes significant amount time (at least in java) - There is a upfront cost to review and write rules to eliminate false positives - There is routine cost to eliminate false positives If we can setup this process, then it will be very ideal and beneficial. It would be good to have an build option to optionally run the scanning before committing the code. Also, by increase/decrease code coverage, do you mean by number of lines or issues? Because number of lines can decrease if a piece of code is optimized. static analysis code coverage for pci audit needs - Key: KAFKA-1722 URL: https://issues.apache.org/jira/browse/KAFKA-1722 Project: Kafka Issue Type: Bug Components: security Reporter: Joe Stein Assignee: Ashish Kumar Singh Fix For: 0.9.0 Code coverage is a measure used to describe the degree to which the source code of a product is tested. A product with high code coverage has been more thoroughly tested and has a lower chance of containing software bugs than a product with low code coverage. Apart from PCI audit needs, increasing user base of Kafka makes it important to increase code coverage of Kafka. Something just can not be improved without being measured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1722) static analysis code coverage for pci audit needs
[ https://issues.apache.org/jira/browse/KAFKA-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281981#comment-14281981 ] Don Bosco Durai commented on KAFKA-1722: Ashish, Coverity is another option. They are free for open source projects. I have been scanning for most of the Hadoop projects. There is already a project created for Kafka (https://scan.coverity.com/projects/1340). I am not sure who is the owner, but if you want I can investigate that path. I had checked with Coverity before and they don't support Scala yet. So it will be only for the java components. static analysis code coverage for pci audit needs - Key: KAFKA-1722 URL: https://issues.apache.org/jira/browse/KAFKA-1722 Project: Kafka Issue Type: Bug Components: security Reporter: Joe Stein Assignee: Ashish Kumar Singh Fix For: 0.9.0 Code coverage is a measure used to describe the degree to which the source code of a product is tested. A product with high code coverage has been more thoroughly tested and has a lower chance of containing software bugs than a product with low code coverage. Apart from PCI audit needs, increasing user base of Kafka makes it important to increase code coverage of Kafka. Something just can not be improved without being measured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KAFKA-1722) static analysis code coverage for pci audit needs
[ https://issues.apache.org/jira/browse/KAFKA-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14281992#comment-14281992 ] Don Bosco Durai commented on KAFKA-1722: coverall also seems to be good. It says on it's website that it supports scala. Not sure to what level. Have you thought about automating the build and submission? Coverity can be be integrated with Travis CI, so it is easy to schedule the build and have results shared with everyone. static analysis code coverage for pci audit needs - Key: KAFKA-1722 URL: https://issues.apache.org/jira/browse/KAFKA-1722 Project: Kafka Issue Type: Bug Components: security Reporter: Joe Stein Assignee: Ashish Kumar Singh Fix For: 0.9.0 Code coverage is a measure used to describe the degree to which the source code of a product is tested. A product with high code coverage has been more thoroughly tested and has a lower chance of containing software bugs than a product with low code coverage. Apart from PCI audit needs, increasing user base of Kafka makes it important to increase code coverage of Kafka. Something just can not be improved without being measured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (KAFKA-1688) Add authorization interface and naive implementation
[ https://issues.apache.org/jira/browse/KAFKA-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178799#comment-14178799 ] Don Bosco Durai edited comment on KAFKA-1688 at 10/21/14 6:33 PM: -- Joe/Jay, I can look into this. Can you assign this to me? Thanks was (Author: bosco): Joe/Jay, I can look into this. Thanks Add authorization interface and naive implementation Key: KAFKA-1688 URL: https://issues.apache.org/jira/browse/KAFKA-1688 Project: Kafka Issue Type: Sub-task Components: security Reporter: Jay Kreps Add a PermissionManager interface as described here: https://cwiki.apache.org/confluence/display/KAFKA/Security (possibly there is a better name?) Implement calls to the PermissionsManager in KafkaApis for the main requests (FetchRequest, ProduceRequest, etc). We will need to add a new error code and exception to the protocol to indicate permission denied. Add a server configuration to give the class you want to instantiate that implements that interface. That class can define its own configuration properties from the main config file. Provide a simple implementation of this interface which just takes a user and ip whitelist and permits those in either of the whitelists to do anything, and denies all others. Rather than writing an integration test for this class we can probably just use this class for the TLS and SASL authentication testing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
