* bump to a pre-8.0 version * export KibanaClient from /lib sub-folder * workaround the problem of the absence of estypes * update es client usage in pacakges * export estypes from another path * import errors from root * import errors from root 2 * update transport import * update import path for /api/types * update import path for /api/types * import errors from top export * use TransportResult instead if ApiResponse * fix errors in client_config * fix src/core/server/saved_objects/migrationsv2/actions/integration_tests/actions.test.ts * use KibanaClient in mock. we dont export the original Client * fix client mocks * fix errors on SO * fix remaining core errors * update estype import path * fix errors in data plugin * fix data_views * fix es_ui_shared * fix errors in interactive_setup * fix errors in ./test folder * add @elastic/transport to the runtime deps * fix errors in packages * fix erros in src/core * fix errors in test/ * fix an error in actions plugin * woraround and fix errors in APM plugin * fix errors in canvas * fix errors in event_log * fix errors in fleet * fix errors in ILM * fix errors in infra * fix errors in ingest_pipeline * fix errors in lens * fix errors in license_management * fix errors in licensing * fix errors in logstash * fix errors in ml * fix errors in monitoring * fix errors in observability * fix errors in rule_registry * fix errors in reporting * fix errors in rule_registry * fix errors in security * fix errors in security_solution * fix errors in snapshot_restore * fix errors in transform * fix errors in UA * fix errors in uptime * fix errors in x-pack/test * fix eslint errors * fix new errors * use default HTTP Connection. Undici does not support agent config options keepAlive and maxSockets * create does not accept require_alias option * update deps * use transport types exported from ES client package * fix ErrorCause | string errors * do not use enum * fix errors in data plugin * update x-pack code * fix transport * fix apm search request * do not crash on reporting * fix kbn-test build * mute reporting error to start * fix ftr build * another attempt * update import path * address or mute new errors * REMOVE me. pin transport version temporarily. * remove deep imports from transport package * fix jest crash * fix product check tests * remove unnecessary ts-expect-error * fix a few failed unit tests * bump to canary 24 * remove unnecessary ts-expect-error * remove dependency on transport * fix types in tests * mute errors in xpack tests * product check doesn;t spam in logs anymore * filterPath --> filter_path * ignoreUnavailable --> ignore_unavailable * ignoreUnavailable --> ignore_unavailable * trackScores --> track_scores * trackTotalHits --> track_total_hits * fix es-arcives * fix data plugin crashes * fix watcher test utils * rollback unnecessary changes * fix another problem in es-archiver * fix scroll. for whatever reason scroll fails when request scroll_id in body * add meta: true in kbn-securitysolution-es-utils * bump client to canary 25 * fix errors in accordance with the es client spec * update securityscolution-es-utils * unify scroll api in reporting and fix tests * fix unit tests in watcher * refactor APM to abort request with AbortController API * fix missing es client calls in tests * fix missing meta in detection engine FTR tests * fix another bunch of errors in js tests * fix wrong coercion * remove test-grep pattern * fix apm unit test * rename terminateAfter to terminate_after in infra plugin * rename terminateAfter to terminate_after in uptime plugin * rename terminateAfter to terminate_after in apm plugin * fix security roles FTR tests * fix reference * fix post_privilidges test * fix post_privilidges * bump client to 26 * add meta for index_management test helpers * remove ts-expect-error caused by bad type in reason * bump client to 27 * REMOVE me. workaround until fixed in the es client * fix incorrect type casting * swtich from camelCase params * use `HttpConnection` for FTR-related clients * bump client to 29 * Revert "REMOVE me. workaround until fixed in the es client" 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.