* bump @elastic/elasticsearch to canary.7
* address errors in core
* address errors in data plugin
* address errors in Alerting team plugins
* remove outdated messages in Lens
* remove unnecessary comments in ML
* address errors in Observability plugin
* address errors in reporting plugin
* address errors in Rule registry plugin
* fix errors in Security plugins
* fix errors in ES-UI plugin
* remove unnecessary union.
* update core tests
* fix kbn-es-archiver
* update to canary 8
* bump to v9
* use new typings
* fix new errors in core
* fix errors in core typeings
* fix type errors in data plugin
* fix type errors in telemetray plugin
* fix data plugin tests
* fix search examples type error
* fix errors in discover plugin
* fix errors in index_pattern_management
* fix type errors in vis_type_*
* fix errors in typings/elasticsearch
* fix type errors in actions plugin
* fix type errors in alerting and apm plugins
* fix type errors in canvas and cases
* fix errors in event_log
* fix type errors in ILM and ingest_pipelines
* fix errors in lens plugin
* fix errors in lists plugin
* fix errors in logstash
* fix errors in metrics_entities
* fix errors in o11y
* fix errors in watcher
* fix errors in uptime
* fix errors in upgrade_assistant
* fix errors in task_manager
* fix errors in stack_alerts
* fix errors in security_solution
* fix errors in rule_registry
* fix errors in snapshot_restore
* fix remaining errors
* fix search intergration tests
* adjust assetion
* bump version to canary.10
* adapt code to new naming schema
* use mapping types provided by the client library
* Revert "adjust assetion"
This reverts commit
|
||
---|---|---|
.. | ||
common | ||
public | ||
server | ||
jest.config.js | ||
kibana.json | ||
README.md | ||
tsconfig.json |
Kibana Security Plugin
See Configuring security in Kibana.
Audit logging
Example
const auditLogger = securitySetup.audit.asScoped(request);
auditLogger.log({
message: 'User is updating dashboard [id=123]',
event: {
action: 'saved_object_update',
category: ['database'],
type: ['change'],
outcome: 'unknown',
},
kibana: {
saved_object: { type: 'dashboard', id: '123' },
},
});
What events should be logged?
The purpose of an audit log is to support compliance, accountability and security by capturing who performed an action, what action was performed and when it occurred. It is not the purpose of an audit log to aid with debugging the system or provide usage statistics.
Kibana guidelines:
Each API call to Kibana will result in a record in the audit log that captures
general information about the request (http_request
event).
In addition to that, any operation that is performed on a resource owned by Kibana (e.g. saved objects) and that falls in the following categories, should be included in the audit log:
- System access (incl. failed attempts due to authentication errors)
- Data reads (incl. failed attempts due to authorisation errors)
- Data writes (incl. failed attempts due to authorisation errors)
If Kibana does not own the resource (e.g. when running queries against user indices), then auditing responsibilities are deferred to Elasticsearch and no additional events will be logged.
Examples:
For a list of audit events that Kibana currently logs see:
docs/user/security/audit-logging.asciidoc
When should an event be logged?
Due to the asynchronous nature of most operations in Kibana, there is an inherent tradeoff between the following logging approaches:
- Logging the intention before performing an operation, leading to false positives if the operation fails downstream.
- Logging the outcome after completing an operation, leading to missing records if Kibana crashes before the response is received.
- Logging both, intention and outcome, leading to unnecessary duplication and noisy/difficult to analyse logs.
Kibana guidelines:
- Write operations should be logged immediately after all authorisation checks have passed, but before the response is received (logging the intention). This ensures that a record of every operation is persisted even in case of an unexpected error.
- Read operations, on the other hand, should be logged after the operation completed (logging the outcome) since we won't know what resources were accessed before receiving the response.
- Be explicit about the timing and outcome of an action in your messaging. (e.g. "User has logged in" vs. "User is creating dashboard")
Can an action trigger multiple events?
- A request to Kibana can perform a combination of different operations, each of which should be captured as separate events.
- Operations that are performed on multiple resources (bulk operations) should be logged as separate events, one for each resource.
- Actions that kick off background tasks should be logged as separate events, one for creating the task and another one for executing it.
- Internal checks, which have been carried out in order to perform an
operation, or errors that occured as a result of an operation should be
logged as an outcome of the operation itself, using the ECS
event.outcome
anderror
fields, instead of logging a separate event. - Multiple events that were part of the same request can be correlated in the
audit log using the ECS
trace.id
property.