[ https://issues.apache.org/jira/browse/KNOX-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16364283#comment-16364283 ]
Kevin Risden edited comment on KNOX-1091 at 2/14/18 3:34 PM: ------------------------------------------------------------- The above testing rules out the following that was in our original infrastructure: * Teradata (SLES 11SP3 OS and custom JVM) * LDAP * Authentication caching * SSL * Multiple topologies Knox 0.9.1 out of the box is vulnerable. I'm going to try the same steps with Knox 1.0.0 (latest release of of this message) to see if the same steps will cause reproduction. was (Author: risdenk): The above testing rules out the following that was in our original infrastructure: * Teradata (SLES 11SP3 OS and custom JVM) * LDAP * Authentication caching * SSL Knox 0.9.1 out of the box is vulnerable. I'm going to try the same steps with Knox 1.0.0 (latest release of of this message) to see if the same steps will cause reproduction. > Knox Audit Logging - duplicate correlation ids > ---------------------------------------------- > > Key: KNOX-1091 > URL: https://issues.apache.org/jira/browse/KNOX-1091 > Project: Apache Knox > Issue Type: Bug > Components: Server > Reporter: Kevin Risden > Priority: Major > > From the Knox User list thread: "Multiple topology audit logging", it came to > my attention that Knox seems to be logging duplicate correlation ids. > Separating out the topic specifically here to dig a bit deeper. > While looking at our Knox audit logs (Knox 0.9 on HDP 2.5) the "correlation > id" doesn't seem to be unique across requests. Is this to be expected? Here > is a snippet (anonymized): > grep 7557c91b-2a48-4e09-aefc-44e9892372da /var/knox/gateway-audit.log > {code} > 17/10/10 12:50:09 > ||7557c91b-2a48-4e09-aefc-44e9892372da|audit|WEBHBASE||||access|uri|/gateway/HADOOPTEST/hbase/hbase/NAMESPACE1:TABLE1/ID1//|unavailable|Request > method: GET > 17/10/10 12:50:09 > ||7557c91b-2a48-4e09-aefc-44e9892372da|audit|WEBHBASE|USER1|||authentication|uri|/gateway/HADOOPPROD/hbase/NAMESPACE2:TABLE2/multiget?row=ID2%2fd%3araw&|success| > 17/10/10 12:50:09 > ||7557c91b-2a48-4e09-aefc-44e9892372da|audit|WEBHBASE|USER1|||authentication|uri|/gateway/HADOOPPROD/hbase/NAMESPACE2:TABLE2/multiget?row=ID2%2fd%3araw&|success|Groups: > [] > 17/10/10 12:50:09 > ||7557c91b-2a48-4e09-aefc-44e9892372da|audit|WEBHBASE|USER1|||dispatch|uri|http://WEBHBASE.example.com:8084/NAMESPACE2:TABLE2/multiget?doAs=USER1&row=ID2%2Fd%3Araw|unavailable|Request > method: GET > 17/10/10 12:50:09 > ||7557c91b-2a48-4e09-aefc-44e9892372da|audit|WEBHBASE|USER1|||dispatch|uri|http://WEBHBASE.example.com:8084/NAMESPACE2:TABLE2/multiget?doAs=USER1&row=ID2%2Fd%3Araw|success|Response > status: 200 > 17/10/10 12:50:09 > ||7557c91b-2a48-4e09-aefc-44e9892372da|audit|WEBHBASE|USER1|||access|uri|/gateway/HADOOPPROD/hbase/NAMESPACE2:TABLE2/multiget?row=ID2%2fd%3araw&|success|Response > status: 200 > 17/10/10 12:50:09 > ||7557c91b-2a48-4e09-aefc-44e9892372da|audit|WEBHBASE||||authentication|principal|USER2|failure|LDAP > authentication failed. > 17/10/10 12:50:09 > ||7557c91b-2a48-4e09-aefc-44e9892372da|audit|WEBHBASE||||access|uri|/gateway/HADOOPTEST/hbase/hbase/NAMESPACE1:TABLE2/ID1//|success|Response > status: 401 > {code} > The things to highlight here for the same correlation id: > * different topologies are being used > * different uris are being used > * different users are being used > Some of the things that we have configured that could impact results: > * authentication caching > * multiple Knox servers > * load balancer in front of Knox -- This message was sent by Atlassian JIRA (v7.6.3#76005)