Skip to content
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

Add generic AuditTrail service #60119

Closed
joshdover opened this issue Mar 13, 2020 · 2 comments
Closed

Add generic AuditTrail service #60119

joshdover opened this issue Mar 13, 2020 · 2 comments
Assignees
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

Comments

@joshdover
Copy link
Contributor

joshdover commented Mar 13, 2020

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 events
    • This is the API that a plugin could use to get all events, enrich with additional data, and forward to a logger.
  • auditTrail.add / addAuditEvent / someOtherName for adding audit events
    • This is the API that Core, OSS plugins, and commercial plugins would use to add domain-events for user actions (eg. Copy to Space). These events are forwarded to any auditors registered with registerAuditor.

Optional feature:

  • auditTrail.openScope
    • Allows a audit events to be associated to a wider "domain-event". For example, we may want to associate specific Elasticsearch API calls to a more descriptive "scope" such as 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:

@joshdover joshdover added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:New Platform enhancement New value added to drive a business result labels Mar 13, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform (Team:Platform)

@mshustov
Copy link
Contributor

The first iteration of the Audit Trail service is in progress #74640.
We will be track new requirements in dedicated issues, so I'm going to close this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

3 participants