[jira] [Created] (KAFKA-5714) Allow whitespaces in the principal name
Alla Tumarkin created KAFKA-5714: Summary: Allow whitespaces in the principal name Key: KAFKA-5714 URL: https://issues.apache.org/jira/browse/KAFKA-5714 Project: Kafka Issue Type: Improvement Components: security Affects Versions: 0.10.2.1 Reporter: Alla Tumarkin Request Improve parser behavior to allow whitespaces in the principal name in the config file, as in: {code} super.users=User:CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown {code} Background Current implementation requires that there are no whitespaces after commas, i.e. {code} super.users=User:CN=Unknown,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown {code} Note: having a semicolon at the end doesn't help, i.e. this does not work either {code} super.users=User:CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown; {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KAFKA-5713) Improve '--group' option to understand strings with wildcards
Alla Tumarkin created KAFKA-5713: Summary: Improve '--group' option to understand strings with wildcards Key: KAFKA-5713 URL: https://issues.apache.org/jira/browse/KAFKA-5713 Project: Kafka Issue Type: Improvement Components: consumer Reporter: Alla Tumarkin Request Implement additional functionality for the '--group' option to be able to take string/wildcard combination, e.g.: {code} bin/kafka-acls --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal "User:CN=Unknown,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown" --consumer --topic test --group mygroup* {code} in order to allow different group names that start with mygroup, e.g.: {code} kafka-console-consumer --zookeeper localhost:2181 --topic test --consumer-property group.id=mygroup1 {code} Background Current functionality only permits to specify an exact group name, like "--group mygroup" or any group as in "group *" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KAFKA-5709) Improve logging to include errors from state-change log in server log
Alla Tumarkin created KAFKA-5709: Summary: Improve logging to include errors from state-change log in server log Key: KAFKA-5709 URL: https://issues.apache.org/jira/browse/KAFKA-5709 Project: Kafka Issue Type: Improvement Components: log Affects Versions: 0.10.2.0 Reporter: Alla Tumarkin Problem The following message was generated over and over again when running kafka-console-producer or kafka-console-consumer with SSL and ACLs enabled {code} WARN Error while fetching metadata with correlation id 1 : {test=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)` endlessly when I run kafka-console-producer or kafka-console-consumer {code} however server log (or authorizer log) did not indicate any problem. Background 1) Initially, security.inter.broker.protocol setting was missing in server.properties, so connection was falling back to using plaintext port (9092), and only state-change.log actually contained the underlying error: {code} [2017-08-04 13:40:48,536] TRACE Controller 0 epoch 6 received response {error_code=31,partitions=[{topic=test,partition=0,error_code=31},{topic=__confluent.support.metrics,partition=0,error_code=31}]} for a request sent to broker localhost:9092 (id: 0 rack: null) (state.change.logger) {code} as per https://kafka.apache.org/protocol#protocol_error_codes {code} CLUSTER_AUTHORIZATION_FAILED31 False Cluster authorization failed. {code} 2) After setting "security.inter.broker.protocol=SSL" the port changed to secure (9093) yet the error in state-change log did not go away: {code} [2017-08-04 13:49:38,462] TRACE Controller 0 epoch 7 received response {error_code=31} for a request sent to broker localhost:9093 (id: 0 rack: null) (state.change.logger) {code} and LEADER_NOT_AVAILABLE was still generated. This time though, kafka-authorizer.log had a better indication of the problem: {code} [2017-08-04 18:17:46,770] DEBUG No acl found for resource Cluster:kafka-cluster, authorized = false (kafka.authorizer.logger) [2017-08-04 18:17:46,770] DEBUG Principal = User:CN=Unknown,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown is Denied Operation = ClusterAction from host = 127.0.0.1 on resource = Cluster:kafka-cluster (kafka.authorizer.logger) {code} The issue being that topic metadata is not propagated successfully from controller to broker since the broker user doesn't have ClusterAction permission. Fixed by {code} bin/kafka-acls --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal "User:CN=Unknown,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown" --operation ClusterAction --cluster {code} Request The debugging is tricky since the controller to broker logging is done in controller/state-change log, not in the main server log. We need to improve the logging on this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (KAFKA-5519) Support for multiple certificates in a single keystore
Alla Tumarkin created KAFKA-5519: Summary: Support for multiple certificates in a single keystore Key: KAFKA-5519 URL: https://issues.apache.org/jira/browse/KAFKA-5519 Project: Kafka Issue Type: New Feature Components: security Affects Versions: 0.10.2.1 Reporter: Alla Tumarkin Background Currently, we need to have a keystore exclusive to the component with exactly one key in it. Looking at the JSSE Reference guide, it seems like we would need to introduce our own KeyManager into the SSLContext which selects a configurable key alias name. https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509KeyManager.html has methods for dealing with aliases. The goal here to use a specific certificate (with proper ACLs set for this client), and not just the first one that matches. Looks like it requires a code change to the SSLChannelBuilder -- This message was sent by Atlassian JIRA (v6.4.14#64029)