-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backport Structured Audit Logging #33894
Backport Structured Audit Logging #33894
Conversation
Changes the format of log events in the audit logfile. It also changes the filename suffix from `_access` to `_audit`. The new entry format is consistent with Elastic Common Schema. Entries are formatted as JSON with no nested objects and field names have a dotted syntax. Moreover, log entries themselves are not spaced by commas and there is exactly one entry per line. In addition, entry fields are ordered, unlike a typical JSON doc, such that a human would not strain his eyes over jumbled fields from one line to the other; the order is defined in the log4j2 properties file. The implementation utilizes the log4j2's `StringMapMessage`. This means that the application builds the log event as a map and the log4j logic (the appender's layout) handle the format internally. The layout, such as the set of printed fields and their order, can be changed at runtime without restarting the node.
Pinging @elastic/es-security |
b05543c
to
1ca9d19
Compare
final MockAppender appender = new MockAppender(name); | ||
attachNewMockAppender(logger, IMPLICIT_APPENDER_NAME, layout); | ||
return logger; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CapturingLogger
can optionally have several appenders. By default it has only one named __implicit
.
} | ||
} | ||
return true; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is empty can optionally check multiple appenders.
.../core/src/test/java/org/elasticsearch/xpack/core/security/audit/logfile/CapturingLogger.java
Outdated
Show resolved
Hide resolved
@@ -1,9 +1,101 @@ | |||
appender.deprecated_audit_rolling.type = RollingFile | |||
appender.deprecated_audit_rolling.name = deprecated_audit_rolling | |||
appender.deprecated_audit_rolling.fileName = ${sys:es.logs.base_path}${sys:file.separator}${sys:es.logs.cluster_name}_access.log |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean that when customers upgrade to say 6.5 version, they will have two logs being populated:
*_access.log
and *_audit.log
at the same time? Depending on whether the customer has done right steps to get away from old logging, it might result into two logs being populated (unknowingly constraining the system).
I think it would be better to keep old one enabled and the new one disabled and let customers go and move from the old appender to new appender.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bizybot See the discussion starting here #31046 (comment)
Basically, Filebeat has to support whatever format we're defaulting too. So if we're not enabling the new appender in 6.x Filebeat will not use this in 6.x, so we might as well not port this to 6.x because Filebeat is the important reason we do this (sort of, the root reason is to get rid of the IndexAuditTrail
, but we need Filebeat to consume or logs before we can do that).
And since we ❤️ our users, we don't want to break any systems they have set up right now that are consuming the present format. So, the compromise is to enable both of them.
I am having a hard time with this. I think we should put in more effort here to validate or keep the existing way as is; I think we can accomplish this by having a special logger for the legacy format. This allows us to keep the pre-existing log statements alongside the new map format that uses a different logger. What do you think? |
@jaymode I am thinking of cherrie-picking the old |
I am good with that approach @albertzaharovits. |
This reverts commit 1ca9d19.
@jaymode I have reverted the "emulated" format logic and cherry-picked |
test this please |
|
run sample packaging tests |
|
https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+pull-request/1647/consoleFull
run gradle build tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a couple of comments. Otherwise LGTM
x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/Security.java
Show resolved
Hide resolved
run gradle build tests |
@ycombinator FYI, this was backported. |
This is the backport of #31931 .
Following the conclusion on #31046 (comment) , this backport resurrects the previous logging format, such that both are enabled side by side for the 6.x releases. This is achieved by adding another appender with it's own pattern layout in the log4j configuration. This pattern layout "emulates" the previous format. Codewise, the same log4j
StringMapMessage
event is used to generate the log lines in both formats. There are truly no guarantees that the "emulated" format is 100% the old one (besides my 🦅 eyes).Unit tests check both layouts by parsing the
log4j2.properties
file as a resource. There are some qa integ tests in the sql projects that parse the audit log when security is enabled. Those only parse the new format.This commit 1ca9d19 adds the "emulated" format (the other commit is the backport).