kerneltime commented on PR #3531: URL: https://github.com/apache/ozone/pull/3531#issuecomment-1181366640
> > There is one complication when adding a separate auth failure audit log. S3 gateway only validates if the auth signature is well-formed. The actual check for credentials occurs at OM. We would need to peek into the exception to know if this is related to auth or a different issue if we want to log it as an AUTH exception entry in the audit log. > > Thanks for the clarification. I introduced the new AUTH marker just because at the time of validating signature, we don't know if the operation is either `READ` or `WRITE` yet. These action/classification is determined manually on-by-one at the endpoint handlers, [e.g.](https://github.com/duongnguyen0/ozone/blob/fcf8aae1fc510e399ffde7013d6649712bc06424/hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3/endpoint/BucketEndpoint.java#L250-L250). > > Yet, as you mentioned, if we're to do that, need to do that consistently for the actual credentials check as well. > > If we don't do that, we can probably infer READ/WRITE base on the web context (e.g. if method is GET/HEAD then READ). However, this is also prone for inconsistence. > > Also, the logged action is another complication is the logged action, which is also [manually put at the endpoint handler](https://github.com/duongnguyen0/ozone/blob/fcf8aae1fc510e399ffde7013d6649712bc06424/hadoop-ozone/s3gateway/src/main/java/org/apache/hadoop/ozone/s3/endpoint/BucketEndpoint.java#L246-L246). So, if the adit log is issued at in the handler, it appears as > > ``` > INFO | S3GAudit | op=CREATE_BUCKET {bucket=myBucket} | Some failure inside the handler > ``` > > But at the time of validating signature, the best we can do is: > > ``` > INFO | S3GAudit | op=PUT /bucket/myBucket {bucket=myBucket} | Error parsing signature... > ``` > > I guess it depends on how consistent we want to introduce in the AUDIT log. Another refactor would be needed to make audit logging a consistent mechanism in S3G. I agree, I think it would be best to not expand the current PR to fix all the issue but to do incrementally and keep the parent Jira open and add tasks as identified. For now, the scope of the changes here look good and it is more important to get the customer initiated logging off the S3G logs first. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
