audit events ignore policies: add support for "actions" attribute

[fbaligand]

Currently, through Logfile audit events ignore policies, we can define rules for users, realms, roles or indices.
But we cannot define rules for actions.

Since Kibana now does a lot of actions with generic "kibana" user to know the user privileges, and this, at each user event, it generates a lot of actions not very interesting for audit purpose. And we can add all monitor actions executed by Kibana user.

=> It would be great to add support for actions in audit events ignore policies.

Doing so, we could add some rule like this one :

xpack.security.audit.logfile:
    events.ignore_filters.evict_monitor_actions.actions: ["cluster:monitor/*"]

[elasticmachine]

Pinging @elastic/es-security

[albertzaharovits]

I agree this is handy, but compared to the other fields that you can do filtering on, users, realms, roles and indices the decision about filtering on action_name requires some internals knowledge, i.e. what the action does. And what the action does can change, and we don't document this kind of changes whatsoever.

That being said, we endeavor to have fine grained actions with well thought of namespaces.
I am on the fence, but leaning on adding this... Any thoughts @jaymode ?

[jaymode]

I think this does have value for those that need to reduce the amount of audit logs in that there are some actions that we might want to leave out such as pings and liveness checks (fall under monitor actions I believe).

[fbaligand]

@jaymode, this is exactly the aim of this issue: "reduce the amount of audit logs" so that only valuable actions are logged for audit.

[Jac2NL]

I agree with @fbaligand. After all, that's what is promised on the tin: "Audit Logging: Have a Record of Who Did What and When. You can filter the activity to only log what you need or log all activity that takes place in the Elastic Stack."

I understand that you don't want to expose too much of the internals but some additional fine grained filtering would be most welcome.

Could you at least label the actions and put them in create / read / update / delete categories? Then we would be able to filter out the bulk of the read actions, for example.

[albertzaharovits]

I realized there is a work around for this, by using log4j2's StructuredDataFilter. For example

appender.audit_rolling.filter.test.type = StructuredDataFilter
appender.audit_rolling.filter.test.onMismatch = NEUTRAL
appender.audit_rolling.filter.test.onMatch = DENY
appender.audit_rolling.filter.test.pair1.type = keyValuePair
appender.audit_rolling.filter.test.pair1.key = action
appender.audit_rolling.filter.test.pair1.value = cluster:admin/xpack/security/user/authenticate
appender.audit_rolling.filter.test.pair2.type = keyValuePair
appender.audit_rolling.filter.test.pair2.key = action
appender.audit_rolling.filter.test.pair2.value = cluster:admin/xpack/security/realm/cache/clear[n]

in the log4j2.properties file, will be ignoring (not print) audit logs for the cluster:admin/xpack/security/user/authenticate and cluster:admin/xpack/security/realm/cache/clear[n] transport actions.
Unfortunately, this does not accept Lucene wildcards and does not "work together" with the ignore policies in ES.

[fbaligand]

thanks for the tip.

[albertzaharovits]

Related #60877