Add generic AuditTrail service #60119
Labels
enhancement
New value added to drive a business result
Feature:New Platform
NeededFor:Security
Team:Core
Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
In order to support #52125, we need to have a core service that supports two key features for auditable events:
auditTrail.registerAuditor
for receiving audit eventsauditTrail.add
/addAuditEvent
/someOtherName
for adding audit eventsregisterAuditor
.Optional feature:
auditTrail.openScope
copy_to_space
. This allows tracing of all commands that were executed in order to fulfill a user request / action.The AuditTrail service does not actually manage where these events eventually get logged or configuring any logging mechanisms. It simply collects all auditable events and forwards them to any interested auditors.
Should this be in Core or an OSS plugin?
I think this is still up for debate. For instance, we could have an OSS plugin that registers itself with Core services through a
registerAuditTrail
API exposed on services like ElasticsearchService or SavedObjectsService.This would help keep the Core API smaller, but may not have many other benefits. It also makes the audit API a bit less discoverable, which may not be preferrable.
Plan
The initial implementation and integration done in #69278
Follow ups:
Continuation-Local Storage
library or use built-in node.js Async HooksRequestContextHandler
we need to considerX-Opaque-Id
implementation for FakeRequests as well. @joshdover Should it be done at Scope-able elasticsearch clients #39430 or PipeX-Opaque-Id
header to AuditTrail logs and Elasticsearch API calls #62018?The text was updated successfully, but these errors were encountered: