Kibana Audit
Configure and interpret Kibana audit logging so you can trace who changed what in Elastic Stack during production operations.
Overview
Kibana Audit is an agent skill for the Operate phase that documents Kibana xpack audit logging configuration, appenders, filters, and correlation with Elasticsearch audit logs.
Install
npx skills add https://github.com/elastic/agent-skills --skill kibana-auditWhat is this skill?
- kibana.yml settings: xpack.security.audit.enabled, appender, ignore_filters
- Rolling-file vs console appenders with time-interval and numeric rotation policies
- Reference table for core audit settings and defaults
- Correlation guidance with Elasticsearch audit logs (per Elastic docs link)
- Restart required after kibana.yml audit configuration changes
Adoption & trust: 1k installs on skills.sh; 502 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Kibana is in production but you cannot reliably audit user and admin actions for compliance or incident review.
Who is it for?
Operators self-hosting Kibana who need file-based audit trails and Elastic-doc-aligned configuration snippets.
Skip if: Greenfield apps with no Elastic Stack, or teams that only need application-level auth logs outside Kibana.
When should I use this skill?
Configuring Kibana xpack audit logging, appenders, ignore_filters, or Elasticsearch audit correlation.
What do I get? / Deliverables
You can enable audit logging with the right appender and ignore filters and know where to read official event schema documentation.
- kibana.yml audit configuration aligned with Elastic documentation
Recommended Skills
Journey fit
Audit logging is an operate concern once Kibana is live and you need accountability and incident reconstruction. Monitoring subphase fits operational visibility; audit trails complement metrics and access logs.
How it compares
Elastic-specific audit reference skill, not a generic SOC2 checklist generator.
Common Questions / FAQ
Who is kibana-audit for?
Solo builders and small teams operating self-managed Kibana who need audit trails for security and troubleshooting.
When should I use kibana-audit?
During operate monitoring setup, after security hardening in ship, or when correlating Kibana actions with Elasticsearch audit events.
Is kibana-audit safe to install?
The skill describes server config paths and logging; review the Security Audits panel on this page before installing.
SKILL.md
READMESKILL.md - Kibana Audit
# Kibana Audit Logging Reference Reference for Kibana audit logging configuration, event types, event schema, and correlation with Elasticsearch audit logs. For full documentation, see the linked Elastic docs. [Full documentation](https://www.elastic.co/guide/en/kibana/current/xpack-security-audit-logging.html) ## Configuration (`kibana.yml`) All Kibana audit settings are configured in `kibana.yml`. A restart is required after changes. ```yaml xpack.security.audit.enabled: true xpack.security.audit.appender: type: rolling-file fileName: /path/to/kibana/data/audit.log policy: type: time-interval interval: 24h strategy: type: numeric max: 10 xpack.security.audit.ignore_filters: - actions: [saved_object_find] categories: [database] ``` ### Core settings | Setting | Type | Default | Description | | ------------------------------------ | ------- | ------- | ------------------------------------------- | | `xpack.security.audit.enabled` | boolean | `false` | Enable Kibana audit logging | | `xpack.security.audit.appender` | object | — | Log output configuration (file type/policy) | | `xpack.security.audit.appender.type` | string | — | `rolling-file` or `console` | ### Rolling-file appender settings | Setting | Type | Default | Description | | ----------------------------------------------- | ------ | ------- | ------------------------------------- | | `xpack.security.audit.appender.fileName` | string | — | Path to the audit log file | | `xpack.security.audit.appender.policy.type` | string | — | `time-interval` or `size-limit` | | `xpack.security.audit.appender.policy.interval` | string | — | Rotation interval (e.g. `24h`) | | `xpack.security.audit.appender.strategy.type` | string | — | `numeric` | | `xpack.security.audit.appender.strategy.max` | number | — | Max number of rotated files to retain | ### Ignore filter settings | Setting | Type | Default | Description | | -------------------------------------------------- | ---- | ------- | -------------------------- | | `xpack.security.audit.ignore_filters` | list | `[]` | Array of filter rules | | `xpack.security.audit.ignore_filters[].actions` | list | — | Event actions to ignore | | `xpack.security.audit.ignore_filters[].categories` | list | — | Event categories to ignore | An event is filtered out if it matches **all** non-empty fields within a single filter entry. ## Event Types | Event action | Description | Category | | ---------------------------------- | -------------------------------------------- | -------------- | | `saved_object_create` | A saved object was created | database | | `saved_object_get` | A saved object was read | database | | `saved_object_update` | A saved object was updated | database | | `saved_object_delete` | A saved object was deleted | database | | `saved_object_find` | A saved object search was performed | database | | `saved_object_open_point_in_time` | A PIT was opened on saved objects | database | | `saved_object_close_point_in_time` | A PIT was closed on saved objects | database | | `saved_object_resolve` | A saved object was resolved (alias redirect) | database | | `login` | A user logged in (success or failure) | authentication | | `logout` | A user logged out