## Summary This PR improves upon the Universal entity definition and entity store work being done to support Asset Inventory by introducing a flag `dynamic` to the definition. The entity store uses an enrich policy in order to retain observed data that falls outside of a `lookbackPeriod` used by the transform that runs the aggregations on the source fields. Normally, we have to specify a retention strategy per each field defined in an entity definition. However, for universal entities, (some of) the fields are dynamically generated based on the JSON extractor pipeline processor, which means we cannot define which strategy to use in the definition itself. To account for this, when `dynamic` is set to `true`, we run an extra ingest pipeline step to process _any field which does not show up in the entity definition_ (ie, has been dynamically generated). At the moment, this pipeline step uses a strategy that always picks the latest value, although int he future, this might need to be configurable, mimicking the ability to choose strategies for "static" fields. See this [doc](https://docs.google.com/document/d/1D8xDtn3HHP65i1Y3eIButacD6ZizyjZZRJB7mxlXzQY/edit?tab=t.0#heading=h.9fz3qtlfzjg7) for more details and [this Figma](https://www.figma.com/board/17dpxrztlM4O120p9qMcNw/Entity-descriptions?node-id=0-1&t=JLcB84l9NxCnudAs-1) for information regarding Entity Store architecture. ## How to test: ### Setup 1. Ensure the default Security Data View exists by navigating to some Security solution UI. 2. Set up the `entity.keyword` builder pipeline * Add it to an index that matches any of the default index patterns in the security data view (eg: `logs-store`) * Make sure and ingested doc contains both `event.ingested` and `@timestamp`. * Easiest way is to add `set` processors to the builder pipeline. 3. Because of the async nature of the field retention process, it is recommended to change some of the default values (explained below) 4. Enable `debugging` by adding `xpack.securitySolution.entityAnalytics.entityStore.developer.pipelineDebugMode: true` to your `kibana.dev.yml` 5. Enable the `assetInventoryStoreEnabled` FF: ``` xpack.securitySolution.enableExperimental: - assetInventoryStoreEnabled ``` ### Interacting with the store In Kibana dev tools: #### Phase 1 1. `POST` some of the example docs to the `logs-store` index 2. Confirm the `entity.keyword` field is being added by the builder pipeline via `GET logs-store/_search`. 3. Initialise the universal entity engine via: `POST kbn:/api/entity_store/engines/universal/init {}` * In order to properly test field retention, it's advisable to reduce the `lookbackPeriod` setting, which means some of the docs in the index might fall out of the window if it takes too long to initialize the engine. Any docs posted when the engine is running should be picked up. * Note that using the UI does not work, as we've specifically removed the Universal engine from the normal Entity Store workflow 4. Check the status of the store is `running` via `GET kbn:/api/entity_store/status` 5. Check that the transform has ran by querying the store index: `GET .entities.v1.latest.security_universal*/_search` * There should be one entity per `related.entity` found in the source index * The fields in the JSON string in `entities.keyword` should appear as fields in the target documents * There should also be a `debug` field and potentially a `historical` field, if enough time has passed for the enrich policy to run. These are normally hidden, but show up when in `debug mode`. #### Phase 2 1. Wait some time (the `INTERVAL` constant) for the enrich policy to populate the `.enrich` indices with the latest data from the store index * Ideally, this will mean that any docs in the source index now fall outside of `lookbackPeriod` of the transform. * Alternatively, you can manually run the enrich poly via: `PUT /_enrich/policy/entity_store_field_retention_universal_default_v1.0.0/_execute`. * It's also possible to update the source docs' timestamps and `event.ingested` to ensure they're outside the `lookbackPeriod` 3. `POST` a new doc to the source index (eg: `logs-store`) * The new doc should either have a new, not yet observed property in `entities.metadata`, or the same fields but with different, new values. 4. Query the store index again. * The entity in question should now reflect the new changes _but preserve the old data too!_ * Existing fields should have been updated to new values * New fields should have been `recursively` merged. Ie, nested fields should not be an issue. * The `historical` field should show the "previous state" of the entity doc. This is useful to confirm that a field's value is, in fact, the "latest" value, whether that comes from a new doc that falls in the lookback window of the transform, or from this `historical` "cache". ### Code #### Default values: * in [`server/lib/entity_analytics/entity_store/entity_definition/universal.ts#L75-L76`]( |
||
---|---|---|
.buildkite | ||
.devcontainer | ||
.github | ||
api_docs | ||
config | ||
dev_docs | ||
docs | ||
examples | ||
kbn_pm | ||
legacy_rfcs | ||
licenses | ||
oas_docs | ||
packages | ||
plugins | ||
scripts | ||
src | ||
test | ||
typings | ||
x-pack | ||
.backportrc.json | ||
.bazelignore | ||
.bazeliskversion | ||
.bazelrc | ||
.bazelrc.common | ||
.bazelversion | ||
.browserslistrc | ||
.editorconfig | ||
.eslintignore | ||
.eslintrc.js | ||
.gitattributes | ||
.gitignore | ||
.i18nrc.json | ||
.node-version | ||
.npmrc | ||
.nvmrc | ||
.prettierignore | ||
.prettierrc | ||
.puppeteerrc | ||
.stylelintignore | ||
.stylelintrc | ||
.telemetryrc.json | ||
.yarnrc | ||
BUILD.bazel | ||
catalog-info.yaml | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
FAQ.md | ||
fleet_packages.json | ||
github_checks_reporter.json | ||
kibana.d.ts | ||
LICENSE.txt | ||
NOTICE.txt | ||
package.json | ||
preinstall_check.js | ||
README.md | ||
renovate.json | ||
RISK_MATRIX.mdx | ||
run_fleet_setup_parallel.sh | ||
SECURITY.md | ||
sonar-project.properties | ||
STYLEGUIDE.mdx | ||
tsconfig.base.json | ||
tsconfig.browser.json | ||
tsconfig.browser_bazel.json | ||
tsconfig.json | ||
TYPESCRIPT.md | ||
updatecli-compose.yaml | ||
versions.json | ||
WORKSPACE.bazel | ||
yarn.lock |
Kibana
Kibana is your window into the Elastic Stack. Specifically, it's a browser-based analytics and search dashboard for Elasticsearch.
- Getting Started
- Documentation
- Version Compatibility with Elasticsearch
- Questions? Problems? Suggestions?
Getting Started
If you just want to try Kibana out, check out the Elastic Stack Getting Started Page to give it a whirl.
If you're interested in diving a bit deeper and getting a taste of Kibana's capabilities, head over to the Kibana Getting Started Page.
Using a Kibana Release
If you want to use a Kibana release in production, give it a test run, or just play around:
- Download the latest version on the Kibana Download Page.
- Learn more about Kibana's features and capabilities on the Kibana Product Page.
- We also offer a hosted version of Kibana on our Cloud Service.
Building and Running Kibana, and/or Contributing Code
You might want to build Kibana locally to contribute some code, test out the latest features, or try out an open PR:
- CONTRIBUTING.md will help you get Kibana up and running.
- If you would like to contribute code, please follow our STYLEGUIDE.mdx.
- For all other questions, check out the FAQ.md and wiki.
Documentation
Visit Elastic.co for the full Kibana documentation.
For information about building the documentation, see the README in elastic/docs.
Version Compatibility with Elasticsearch
Ideally, you should be running Elasticsearch and Kibana with matching version numbers. If your Elasticsearch has an older version number or a newer major number than Kibana, then Kibana will fail to run. If Elasticsearch has a newer minor or patch number than Kibana, then the Kibana Server will log a warning.
Note: The version numbers below are only examples, meant to illustrate the relationships between different types of version numbers.
Situation | Example Kibana version | Example ES version | Outcome |
---|---|---|---|
Versions are the same. | 7.15.1 | 7.15.1 | 💚 OK |
ES patch number is newer. | 7.15.0 | 7.15.1 | ⚠️ Logged warning |
ES minor number is newer. | 7.14.2 | 7.15.0 | ⚠️ Logged warning |
ES major number is newer. | 7.15.1 | 8.0.0 | 🚫 Fatal error |
ES patch number is older. | 7.15.1 | 7.15.0 | ⚠️ Logged warning |
ES minor number is older. | 7.15.1 | 7.14.2 | 🚫 Fatal error |
ES major number is older. | 8.0.0 | 7.15.1 | 🚫 Fatal error |
Questions? Problems? Suggestions?
- If you've found a bug or want to request a feature, please create a GitHub Issue. Please check to make sure someone else hasn't already created an issue for the same topic.
- Need help using Kibana? Ask away on our Kibana Discuss Forum and a fellow community member or Elastic engineer will be glad to help you out.