About gpinnadhari

gpinnadhari · ‎07-10-2018

This is the remote ip > The address I saw in the log was not the IP of either the knox's curl client or even the LB that is in the path between the client and knox. So not sure how this field is supposed to help in auditing. It could possibly be due to - cluster's network is NAT-ed before hitting LB. event time is not followed by a | > So it does seem like a cosmetic bug in AuditLayout code I dont think knox will try to interpret the actual response > Thanks for the confirmation Felix. Just a thought, this seems counter-intuitive considering audit's purpose should be to record whether the operation was allowed or denied. Seems like it is lacking some context. Thanks for your inputs.

gpinnadhari · ‎07-06-2018

Trying to interpret the contents of knox's gateway-audit.log, per https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.5/bk_security/content/audit_log_files.html However, there are some gaps and either the doc or the code/logger seems to be lacking. Sample audit entry: 18/07/06 10:55:56 ||a33a162d-2343-4943-8b7c-f899c230f5a1|audit|10.12.103.228|WEBHDFS||||access|uri|/gateway/XYZ/webhdfs/v1/tmp?op=LISTSTATUS|success|Response status: 401 Same audit entry with fields mapped, per doc: EVENT_PUBLISHING_TIME |18/07/06 10:55:56 ** ROOT_REQUEST_ID PARENT_REQUEST_ID | REQUEST_ID |a33a162d-2343-4943-8b7c-f899c230f5a1 LOGGER_NAME |audit ** ??? |10.12.103.228 TARGET_SERVICE_NAME |WEBHDFS >> USER_NAME | PROXY_USER_NAME | SYSTEM_USER_NAME | ACTION |access RESOURCE_TYPE |uri RESOURCE_NAME |/gateway/XYZ/webhdfs/v1/tmp?op=LISTSTATUS OUTCOME |success LOGGING_MESSAGE |Response status: 401 1. As seen, there is an IP address in the log that doesnt seem to have an equivalent/document field name. What is this address supposed to be? 2. Also, is it intentional to squish "EVENT_PUBLISHING_TIME" and "ROOT_REQUEST_ID" into one column? I understand ROOT_REQUEST_ID is a reserved/empty field but not sure why it is merged with EVENT_PUBLISHING_TIME in the actual log entry. Looks like a bug. 3. The outcome field is misleading. Does it say "succeeded" because a response was sent back to the client? If so, then while technically correct, it does not accurately reflect the status of the operation as it actually failed as seen by the 401 / unauthorized response status. 4. Why could the USER_NAME be missing in the audit entry? I see that when a curl request is directly targetted to a Knox server, the entry shows a tagged username and the response status is 200 / OK. But when the same request is targetted to a LB fronting the Knox server, the USER_NAME is unpopulated and the request fails.

gpinnadhari · ‎11-21-2017

You can try : 0: jdbc:phoenix:> !primarykeys $TABLE_NAME +------------+--------------+-------------+------------------------+----------+----------+--------------+------------+------------+-+ | TABLE_CAT | TABLE_SCHEM | TABLE_NAME | COLUMN_NAME | KEY_SEQ | PK_NAME | ASC_OR_DESC | DATA_TYPE | TYPE_NAME | | +------------+--------------+-------------+------------------------+----------+----------+--------------+------------+------------+-+ | | $SCHEMA | $TABLE | col1 | 1 | PK | A | 12 | VARCHAR | | | | $SCHEMA | $TABLE | col2 | 2 | PK | A | 12 | VARCHAR | | +------------+--------------+-------------+------------------------+----------+----------+--------------+------------+------------+-+

Online	Offline
Last Visited	‎10-18-2023 04:23 PM

Member Since	‎05-19-2016 01:15 AM
Last Visited	‎10-18-2023 04:23 PM
Posts	11

Cloudera Community

Re: Interpreting knox's gateway-audit.log

Interpreting knox's gateway-audit.log

Re: describe phoenix table to find primary key