You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "Vladimir Tkhir (JIRA)" <ji...@apache.org> on 2014/02/21 10:14:19 UTC

[jira] [Commented] (KNOX-272) Auditing content refinement

    [ https://issues.apache.org/jira/browse/KNOX-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908109#comment-13908109 ] 

Vladimir Tkhir commented on KNOX-272:
-------------------------------------

{quote}
{noformat}
# Redeployment
14/02/20 16:06:39 |||audit|||||redeploy|topology|sandbox|unavailable|
* I think there should be something in one of the user columns.
{noformat}
{quote}
It can be a process owner, but i think usage of user that changed topology file would be more logical. But it would be hard to get this user
 
{quote}
{noformat}
# Access (status/outcome)
14/02/20 16:15:11 ||...|audit|WEBHBASE|guest|hdfs||access|uri|...|success|Response status: 405
* I think that >=400 should use a failure outcome.
{noformat}
{quote}

It's hard to determine correct answer here. If for example WebHDFS returned some error code and Knox than propagating response to client, than there is no failure on Knox side.

{quote}
{noformat}
# Knox Service
* What in these lines would identify this as a Knox audit record if/when it is centrally combined?
{noformat}
{quote}

Component and service names currently present in LoggingEvent and names are populated with "knox" value. I think AuditLayout should be updated to contain service and component names. 

> Auditing content refinement 
> ----------------------------
>
>                 Key: KNOX-272
>                 URL: https://issues.apache.org/jira/browse/KNOX-272
>             Project: Apache Knox
>          Issue Type: Improvement
>          Components: Server
>    Affects Versions: 0.4.0
>            Reporter: Kevin Minder
>             Fix For: 0.4.0
>
>
> # User Columns
> * It still isn't clear to me exactly how we expect these to be used consistently.
> # Authentication Failure
> 14/02/20 16:14:45 ||...|audit|WEBHBASE||||access|uri|...|unavailable|
> 14/02/20 16:14:45 ||...|audit|WEBHBASE||||access|uri|...|success|Response status: 401
> * We need really see if we can figure out a way to log an authentication|failre
> # Redeployment
> 14/02/20 16:06:39 |||audit|||||redeploy|topology|sandbox|unavailable|
> * I think there should be something in one of the user columns.
> # Access (two records)
> 14/02/20 16:13:43 ||...|audit|WEBHBASE||||access|uri|...|unavailable|
> 14/02/20 16:15:11 ||...|audit|WEBHBASE|guest|hdfs||access|uri|...|success|Response status: 405
> * I'm questioning the value of the first record but I understand that it might be important to have this to "bracket" the request processing.
> # Access (status/outcome)
> 14/02/20 16:15:11 ||...|audit|WEBHBASE|guest|hdfs||access|uri|...|success|Response status: 405
> * I think that >=400 should use a failure outcome.
> # Identity Mapping (Three Records)
> 14/02/20 16:15:11 ||...|audit|WEBHBASE|guest|hdfs||identity-mapping|principal|guest|success|
> 14/02/20 16:15:11 ||...|audit|WEBHBASE|guest|hdfs||identity-mapping|principal|hdfs|success|Groups: [admin]
> 14/02/20 16:15:11 ||...|audit|WEBHBASE|guest|hdfs||identity-mapping|principal|*|success|Groups: [users]
> * Three records seems excessive.  Can these be meaningfully combined?
> # Knox Service
> * What in these lines would identify this as a Knox audit record if/when it is centrally combined?



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)