The knowledge team is a codeowner of the other data access plugins and
should be on Logs.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## FTR tests for manual rule run:
For all rule types we cover
- that manual rule run can generate alerts
- that it not create duplicates (except case for threshold and esql)
- that suppression work per execution (except trhreshold)
- that suppression work per time period
For IM rule also covered that `threat_query `not affected by manual rule
run range
Also covered several common cases, but tests are created only for custom
query rule:
- disabling rule, after manual rule run execution started, not affecting
manual run executions
- changing name of the rule after manual rule run started, not affecting
alert generated by manual rule run executions
related:
https://github.com/elastic/security-team/issues/9826#issue-2379978026
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Contributes to:
- https://github.com/elastic/security-team/issues/9954
The PR contains the base for the `DistributionBar` component to be used
in the new Entity Flyout Insights.
Not included:
- badges per distribution with the number of documents and pretty names
- on hover interaction
## Screenshots
<img width="980" alt="Screenshot 2024-07-17 at 15 13 48"
src="https://github.com/user-attachments/assets/f2ca53ee-c054-4923-aa3f-7dd4017754cb">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- [x] This is an improvement pr to move all the avc banner logic into a
reusable kibana package (security solution and fleet integrations)
- [x] Compresses the svg used in the banner's background
- [x] Fixes a bug where the blog link didn't previously open in a new
tab
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Update i18n tools after the main packages upgrade. This upgrade makes
use of formatJS tooling instead of fully implementing the parsers
ourselves. It also changes our custom AST parsing from babel to the
typescript compiler.
- [x] i18n exrtract
- [x] i18n check
- [x] i18n integrate
- [x] add test cases for formatjs runner
- [x] Make sure all CLI flags are handled properly
- [x] Update tooling readme
Closes https://github.com/elastic/kibana/issues/180616
Closes https://github.com/elastic/kibana/issues/187703
### Note to reviewers
Teams outside operations and core are probably requested to review
because the `i18n_check` fixed malformed i18n messages in your plugins.
Please check and approve :elasticheart:
## Summary
https://github.com/elastic/kibana/pull/183611
I moved x-pack/test/security_solution_endpoint to
x-pack/test/security_solution_api_integration in
https://github.com/elastic/kibana/pull/183611 as I thought all the tests
regarding Security Solution should live there.
However security_solution_endpoint are not api tests , they are UI
tests. After discussions, we decided to move security_solution_endpoint
back to `x-pack/test/`
The two files below are shared between
`x-pack/test/security_solution_api_integration/test_suites/security_solution_endpoint_api_int`
and `x-pack/test/security_solution_endpoint`, moved them to `services`
in this PR to avoid type check confusion.
-
x-pack/test/common/services/security_solution/endpoint_data_stream_helpers.ts
-
x-pack/test/common/services/security_solution/endpoint_registry_helpers.ts
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Close https://github.com/elastic/kibana/issues/183686
Adds a new sorting option "Recently viewed". Recently viewed dashboards
will be shown at the top of the list. The remaining dashboards are
sorted by last updated at.
- This is a default option unless another option was explicitly selected
before (and saved in local storage)
- If there are no recently viewed dashboards, then this sorting option
is hidden, and "last updated at" is default like before
- This option is only added to the dashboard listing
Implementation:
- Recently viewed dashboard are stored in local storage as a queue with
20 items max
- I reused the existing RecentlyAccessedService we've been using for
sidenav's recently viewed section. For this, I moved it to a separate
package. The service already handles a lot of edge cases like spaces,
key hashing, and deduping.
- The sorting part in EUITable is a bit hacky. It doesn't support custom
internal sorting (like we do with title and lastUpdatedAt), so I had to
sort the list myself and then tell EUITable not to do any sorting in
case "Recently viewed" option is selected. [slack
discussion](https://elastic.slack.com/archives/C7QC1JV6F/p1720008717120589)
<img width="1265" alt="Screenshot 2024-07-05 at 10 59 25"
src="9cc46fd2-4270-494f-9272-302007a7efc0">
## Summary
Renames `@kbn/text-based-languages` plugin to `@kbn/esql` plugin. This
has been discussed internally, the rationale is that now there will be
only one language: ES|QL; and we may use this plugin for ES|QL related
HTTP routes.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Adds solution-agnostic components to create hierarchical alerts grouping
UIs, adapting the original implementation from Security Solution.
Closes#184398
## To Verify
For existing usages of the `@kbn/grouping` package: verify that the
grouped UIs work correctly (Security Alerts, Cloud Security Posture).
New alerting UI components: checkout
https://github.com/elastic/kibana/pull/183114 (PoC PR), where the
updated `@kbn/grouping` package and these new components are used in
Observability's main Alerts page.
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Gerard Soldevila <gerard.soldevila@elastic.co>
Co-authored-by: Vadim Kibana <82822460+vadimkibana@users.noreply.github.com>
Co-authored-by: Alex Szabo <alex.szabo@elastic.co>
Co-authored-by: Tre <wayne.seymour@elastic.co>
## Summary
Renames the experimental asset_manager plugin (never
documented/officially released) into entity_manager. I've used `node
scripts/lint_ts_projects --fix` and `node scripts/lint_packages.js
--fix` to help with the procedure and also renamed manually the
asset_manager references left.
The change also removes the deprecated asset_manager code, including the
`assetManager.alphaEnabled` plugin configuration. This means
entityManager plugin will be enabled by default.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This consumes the security solution's API key flyout and token selector
in Serverless search to have a consistent experience across the stack.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR updates the Rollup badge in the indices list and the data views
list so that it provides deprecation information. The tooltip component
is stored in a new package to avoid cyclical dependencies as it is used
in both the Index management plugin and in the Data views management
plugin.
<details><summary>Screenshots</summary>
<img width="1679" alt="Screenshot 2024-06-17 at 18 08 35"
src="1d3daa9d-3f62-49f8-803f-1b3d4605f9a4">
<img width="1679" alt="Screenshot 2024-06-17 at 18 08 53"
src="2e88d119-88e7-4d01-bab9-bc2add82b91c">
<img width="1679" alt="Screenshot 2024-06-17 at 18 09 18"
src="29d3d3f2-de46-45ea-96a1-b83495d122df">
</details>
**How to test:**
1. Start Es and Kibana
2. Add the sample data "Sample web logs"
3. Elasticsearch only allows creating a rollup job if there is an
existing rollup usage in the cluster. To simulate rollup usage, create a
mock rollup index through Console:
```
PUT /mock_rollup_index
{
"mappings": {
"_meta": {
"_rollup": {
"id": "logs_job"
}
}
}
}
```
4. Create a sample rollup job through Console:
```
PUT _rollup/job/logs_job
{
"id": "logs_job",
"index_pattern": "kibana_sample_data_logs",
"rollup_index": "rollup_logstash",
"cron": "* * * * * ?",
"page_size": 1000,
"groups": {
"date_histogram": {
"interval": "60m",
"delay": "7d",
"time_zone": "UTC",
"field": "@timestamp"
},
"terms": {
"fields": [
"geo.src",
"machine.os.keyword"
]
},
"histogram": {
"interval": "1003",
"fields": [
"bytes",
"memory"
]
}
}
}
```
5. Delete the mock rollup index since it causes issues for the rollup
API that we use to fetch rollup indices:
`DELETE /mock_rollup_index`
6. Navigate to Index Management and toggle the "Include rollup indices"
switch
7. Verify that the rollup indices have the deprecation badge.
8. Navigate to Data Views and create a rollup data view with index
pattern that matches the created rollup index (`rollup*`).
9. In the list of data views, verify that the rollup data view has the
correct rollup deprecation badge.
10. Click on the rollup data view and verify that the details panel also
has the deprecation badge.
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/66716
Improves code editors in Anomaly detection, Data frame analytics and
Transform wizards with autocomplete, data types validation and inline
documentation from elasticsearch specification.
Adds a package with JSON schemas extracted from the [openapi output of
elasticsearch-specification](https://github.com/elastic/elasticsearch-specification/tree/main/output/openapi).
Schema file is generated per editor/endpoint, keeping only relevant
components.
To test the script locally, execute
```
yarn run jsonSchema
```
from `/x-pack/packages/ml/json_schemas`.
By default it assumes that your `elasticsearch-specification` folder is
located next to the `kibana` repo, but you can also provide a path to
`openapi` file as a parameter, e.g. `yarn run jsonSchema
/Users/my_user/dev/elasticsearch-specification/output/openapi/elasticsearch-serverless-openapi.json`
#### How JSON files are served
JSON files are asynchronously imported at the React component level and
passed to the `CodeEditor` instances on mount.
Initially I tried different approaches to take advantage of CDN, but
unfortunately it didn't work out:
##### Using static assets
I made an attempt to retrieve a URL to the JSON schema file as a static
asset using Kibana service
```typescript
const schemaJsonAsset = http?.staticAssets.getPluginAssetHref('my_schema.json') ?? '';
```
and passing it as part of the schema definition, but the browser was
blocking a request 🤔
##### Using raw loader
Approach with a raw loader also didn't succeed.
```typescript
import mySchema from '!!raw-loader!./my_schema.json';
```
<details>
<summary>See error </summary>
```
ERROR in
./public/app/sections/create_transform/components/advanced_pivot_editor/my_schema.json
(/Users/dimaarnautov/Repos/kibana/node_modules/raw-loader/dist/cjs.js!./public/app/sections/create_transform/components/advanced_pivot_editor/my_schema.json)
│ Module parse failed: Unexpected token 'e', "export def"... is not
valid JSON while parsing 'export default "{\n \"type\": \"object\'
│ File was processed with these loaders:
│ * ../../../node_modules/raw-loader/dist/cjs.js
│ You may need an additional loader to handle the result of these
loaders.
│ SyntaxError: Unexpected token 'e', "export def"... is not valid JSON
while parsing 'export default "{\n \"type\": \"object\'
│ at JSON.parse (<anonymous>)
│ at parseJson
(/Users/dimaarnautov/Repos/kibana/node_modules/json-parse-better-errors/index.js:7:17)
│ at JsonParser.parse
(/Users/dimaarnautov/Repos/kibana/node_modules/webpack/lib/JsonParser.js:16:16)
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/webpack/lib/NormalModule.js:482:32
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/webpack/lib/NormalModule.js:358:12
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:373:3
│ at iterateNormalLoaders
(/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
│ at iterateNormalLoaders
(/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:236:3
│ at runSyncOrAsync
(/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:130:11)
│ at iterateNormalLoaders
(/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:232:2)
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/loader-runner/lib/LoaderRunner.js:205:4
│ at
/Users/dimaarnautov/Repos/kibana/node_modules/webpack/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:85:15
│ at processTicksAndRejections (node:internal/process/task_queues:77:11)
```
</details>
### Checklist
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Summary
Introducing the `search_homepage` plugin along with integration into
`enterprise_search` and `serverless_search` behind a feature flag. This
will allow implementing the feature gated behind the feature flag.
To test these changes you can enable the feature flag with the Kibana
Dev Console using the following command:
```
POST kbn:/internal/kibana/settings/searchHomepage:homepageEnabled
{"value": true}
```
You can then disable the feature flag with the following command:
```
DELETE kbn:/internal/kibana/settings/searchHomepage:homepageEnabled
```
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Close https://github.com/elastic/kibana-team/issues/898
- Show createdAt, createdBy, updatedAt, updatedBy in info flyout. Add a
bit of special handling for managed objects and when info is not
available.
- I had to extract some components into a separate package to use them
in contentEditor package
- tiny tweaks to column width and "no creator" state
**Unknown creator:**
**For managed objects:**
**Just created, no updates yet**
## Summary
This PR does a major refactor of Response Actions functionality usage
outside of the `management` section of the code base. The impact
(although should be transparent from a user's standpoint) is mostly to
the Alert Details "Take Action" menu and specifically to the
"Isolate/Release" and "Respond" menu actions and the UI's it displays
when clicked. The changes can be summarized as:
- Centralized (moved) all code associated with Response Actions under
one of the following three directories:
- `public/common/component/endpoint`
- `public/common/hooks/endpoint`
- `public/common/lib/endpoint`
- Most changed files in this PR were a result of this activity
- Deleted several utilities that were used to determine the Alert's host
support for Response actions and replaced with a single `hook`
(`useAlertResponseActionsSupport()`)
- The "Isolate/Release" Take Action menu item now behaves similar to the
"Respond" menu option (on Alerts) in that:
- Its only NOT displayed if the user is not authorized to use it
- It will show up as disabled while we are attempting to determine
support for response actions on the alert's host
- Tooltips will be displayed when options is disabled
## Summary
This is a PR to add a new backend plugin (frontend will be done in
separate [PR](https://github.com/elastic/kibana/pull/184546)).
The purpose of the plugin is to provide a set of API routes that is used
to perform a variety of GenAI workflows to generate new integrations
based on provided inputs.
It reuses the existing GenAI connectors for its LLM communication, and
provides a set of API's to create ECS mapping, Categorization, Related
Fields and an API to generate the actual integration package zip, which
is forwarded to the UI component.
### Planned follow-up changes:
As the PR is getting way too large, some planned changes would be added
in much smaller follow-ups. This includes mostly more improved try/catch
for certain routes, adding debug/error log entries where relevant,
especially for the API endpoints themself, some more unit and end2end
tests.
- OpenAPI spec for the API will be handled in a separate PR
- All the missing unit tests will be added as a followup PR
### Testing
The `integration_assistant` plugin will be disabled by default while
it's being implemented so we can iterate and merge partial PRs without
interfering with the releases. This config will work as our feature
flag:
6aefd4ff7b/x-pack/plugins/integration_assistant/server/config.ts (L11-L13)
To test it add this to your _kibana.dev.yml_:
```
xpack.integration_assistant.enabled: true
```
### Checklist
Delete any items that are not applicable to this PR.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Patryk Kopycinski <contact@patrykkopycinski.com>
Co-authored-by: Sergi Massaneda <sergi.massaneda@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Bharat Pasupula <saibharatchandra.pasupula@elastic.co>
Co-authored-by: Bharat Pasupula <123897612+bhapas@users.noreply.github.com>
resolves: https://github.com/elastic/kibana/issues/181325
## Summary
Adds a new task claiming strategy `unsafe_mget`, which can be used instead of
the default one `default`. Add the following to your `kibana.yml` to
enable it:
xpack.task_manager.claim_strategy: 'unsafe_mget'
## Description
In this PR, we implemented a view for managing inference endpoints. The
changes include the following items for both **Serverless** and
**Stack**.
- A blank page will be displayed if no inference endpoints are
available.
- A page displaying a list of inference endpoints. The user can view
various details about each endpoint, such as the endpoint itself, the
provider, and the type. The table supports pagination and sorting.
- Users can add a new inference endpoint using Elasticsearch models and
third-party APIs, including Hugging Face, Cohere, and OpenAI.
To keep the changes in this PR manageable, the following items are **out
of scope** but will be added in subsequent PRs
- Option to delete an inference endpoint
- Filtering and Search bar
- Information about allocations, thread.
- Icons for **Provider**
- Deployment status of underlying trained models
## Empty page in Stack Management
e2064ee8-3623-457f-8a04-19603e97e815
## Page with all inference endpoints in Stack Management
89bec450-1569-4425-b013-5058b577b95a
## Inference Endpoints Management in Serverless
bd8b6b71-0e09-49f4-aa9a-19338a1da225
---------
Co-authored-by: Liam Thompson <32779855+leemthompo@users.noreply.github.com>
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR creates a package to expose tools for managing feature flags in
the ResponseOps codebase.
Usage:
```
const featureFlagService = createFeatureFlagService(['test.myFeature', 'test.myFeature.subFeature']);
if (featureFlagService.isFeatureFlagSet('test.myFeature')) {
// my feature code
}
```
The code is typed so if you do
`featureFlagService.isFeatureFlagSet('foo')` and `foo` is not part of
the feature flags set TS will report an error.
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Create the Investigate plugin (naming TBD). Part of
https://github.com/elastic/kibana/pull/183293, splitting up the work in
several PRs.
The investigate plugin is mostly a registry to allow plugins to register
their widgets without creating dependency issues.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR extends the features plugin to accept feature definition
overrides via Kibana configuration. The functionality is limited to the
Serverless offering only. Additionally, the PR updates Kibana serverless
configurations to include overrides based on the "simplified feature
toggles" proposals discussed with the solution teams.
The configuration might look like this:
```yaml
## Fine-tune the feature privileges.
xpack.features.overrides:
dashboard:
privileges:
### Dashboard's `All` feature privilege should implicitly
### grant `All` access to Maps and Visualize features.
all.composedOf:
- feature: "maps"
privileges: [ "all" ]
- feature: "visualize"
privileges: [ "all" ]
### All Dashboard sub-feature privileges should be hidden:
### reporting capabilities will be granted via dedicated
### Reporting feature and short URL sub-feature privilege
### should be granted for both `All` and `Read`.
subFeatures.privileges:
download_csv_report.disabled: true
url_create:
disabled: true
includeIn: "read"
### Maps feature is disabled since it's automatically granted by Dashboard feature.
maps.disabled: true
```
## How to test
Log in as the `admin` using SAML and navigate to the `Custom roles`
management section to edit role and see tuned role management UX:
<p align="center">
<img
src="ad6e4b07-53bd-4f5a-ae91-66d6534c711a"
/>
<img
src="8ab4d5a3-f719-42d5-a278-3aee87603c33"
/>
</p>
### Search project
```bash
yarn es serverless --projectType=es --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=es --ssl --xpack.security.roleManagementEnabled=true
```
Refer to the proposal document, `config/serverless.yml`, and
`config/serverless.es.yml` in this PR to see the specific changes made
for your project type:
Create a custom `custom-search` role and re-login as the user with this
role to test your project type (you need to manually type role name if
the role selector):
<p align="center">
<img
src="5088320b-3cc8-4de9-984c-d70fc6277659"
/>
</p>
### Observability project
```bash
yarn es serverless --projectType=oblt --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=oblt --ssl --xpack.security.roleManagementEnabled=true
```
Refer to the proposal document, `config/serverless.yml`, and
`config/serverless.oblt.yml` in this PR to see the specific changes made
for your project type:
Create a custom `custom-o11y` role and re-login as the user with this
role to test your project type (you need to manually type role name if
the role selector):
<p align="center">
<img
src="110572b1-f08a-4427-a687-5c2e0240a36b"
/>
</p>
### Security project
```bash
yarn es serverless --projectType=security --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=security --ssl --xpack.security.roleManagementEnabled=true
```
Refer to the proposal document, `config/serverless.yml`, and
`config/serverless.security.yml` in this PR to see the specific changes
made for your project type:
Create a custom `custom-security` role and re-login as the user with
this role to test your project type (you need to manually type role name
if the role selector):
<p align="center">
<img
src="2bec6ae2-8d19-4142-a479-9a81bc1fca14"
/>
</p>
__Fixes: https://github.com/elastic/kibana/issues/178963__
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/3331
Given the needs described in the linked issue about having a centralized
and async way to consume field metadata across Kibana, this work focuses
on providing server/client services to consume field metadata on demand
from static ECS definition and integration manifests, with the chance to
extend further the possible resolution sources.
3b2d9027-5c29-4081-ab17-1b43618c62a7
## 💡 Reviewers hints
This PR got quite long as it involves and touches different parts of the
codebase, so I'll break down the interesting parts for an easier review.
More details, code examples and mechanics description can be found in
the README file for the plugin.
### `@kbn/fields-metadata-plugin`
To avoid bundling and consuming the whole ECS static definition
client-side, a new plugin `@kbn/fields-metadata-plugin` is created to
expose the server/client services which enable retrieving only the
fields needed on a use-case basis.
### FieldsMetadataService server side
A `FieldsMetadataService` is instantiated on the plugin setup/start
server lifecycle, exposing a client to consume the fields and setup
tools for registering external dependencies.
The start contract exposes a `FieldsMetadataClient` instance. With this,
any application in Kibana can query for some fields using the available
methods, currently:
- `FieldsMetadataClient.prototype.getByName()`: retrieves a single
`FieldMetadata` instance.
- `FieldsMetadataClient.prototype.find()`: retrieves a record of
matching `FieldMetadata` instances.
`FieldsMetadataClient` is instantiated with the source repositories
dependencies. They act as encapsulated sources which are responsible for
fetching fields from their related source. Currently, there are 2 field
repository sources used in the resolution step, but we can use this
concept to extend the resolution step in future with more sources (LLM,
OTel, ...).
The currently used sources are:
- `EcsFieldsRepository`: allows fetching static ECS field metadata.
- `IntegrationFieldsRepository`: allows fetching fields from an
integration package from EPR, where the fields metadata are stored. To
correctly consume these fields, the `fleet` plugin must be enabled,
otherwise, the service won't be able to access the registered fields
extractor implemented with the fleet services.
As this service performs a more expensive retrieval process than the
`EcsFieldsRepository` constant complexity access, a caching layer is
applied to the retrieved results from the external source to minimize
latency.
### Fields metadata API
To expose this service to the client, a first API endpoint is created to
find field metadata and filter the results to minimize the served
payload.
- `GET /internal/fields_metadata/find` supports some initial query
parameters to narrow the fields' search.
### FieldsMetadataService client side
As we have a server-side `FieldsMetadataService`, we need a client
counterpart to consume the exposed API safely and go through the
validation steps.
The client `FieldsMetadataService` works similarly to the server-side
one, exposing a client which is returned by the public start contract of
the plugin, allowing any other to directly use fields metadata
client-side.
This client would work well with existing state management solutions, as
it's not decoupled from any library.
### useFieldsMetadata
For simpler use cases where we need a quick and easy way to consume
fields metadata client-side, the plugin start contract also exposes a
`useFieldsMetadata` react custom hook, which is pre-created accessing
the FieldsMetadataService client described above. It is important to
retrieve the hook from the start contract of this plugin, as it already
gets all the required dependencies injected minimizing the effort on the
consumer side.
The `UnifiedDocViewer` plugin changes exemplify how we can use this hook
to access and filter fields' metadata quickly.
### `registerIntegrationFieldsExtractor` (@elastic/fleet)
Getting fields from an integration dataset is more complex than
accessing a static dictionary of ECS fields, and to achieve that we need
access to the PackageService implemented by the fleet team.
To get access to the package, maintain a proper separation of concerns
and avoid a direct dependency on the fleet plugin, some actions were
taken:
- the `PackageService.prototype.getPackageFieldsMetadata()` method is
implemented to keep the knowledge about retrieving package details on
this service instead of mixing it on parallel services.
- a fleet `registerIntegrationFieldsExtractor` service is created and
used during the fleet plugin setup to register a callback that accesses
the service as an internal user and retrieves the fields by the given
parameters.
- the fields metadata plugin returns a
`registerIntegrationFieldsExtractor` function from its server setup so
that we can use it to register the above-mentioned callback that
retrieves fields from an integration.
This inverts the dependency between `fields_metadata` and `fleet`
plugins so that the `fields_metadata` plugin keeps zero dependencies on
external apps.
## Adoption
We currently have places where the `@elastic/ecs` package is directly
accessed and where we might be able to refactor the codebase to consume
this service.
**[EcsFlat usages in
Kibana](https://github.com/search?q=repo%3Aelastic%2Fkibana%20EcsFlat&type=code)**
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
https://github.com/elastic/kibana/issues/181683
This PR moves
1. x-pack/test/security_solution_endpoint_api_int to
`x-pack/test/security_solution_api_integration/test_suites/security_solution_endpoint_api_int`
2. x-pack/test/security_solution_endpoint to
`x-pack/test/security_solution_api_integration/test_suites/security_solution_endpoint`
3. x-pack/test/timeline to
`x-pack/test/security_solution_api_integration/test_suites/investigation/timeline`
### To test:
1. ```cd x-pack/test/security_solution_api_integration```
2. ```node ../../../scripts/functional_tests_server.js --config
./test_suites/security_solution_endpoint/serverless.endpoint.config.ts```
Once the server is launched (you might need Docker to run the serverless
tests), open another terminal, go to the same path, and execute the
command appears in the original:
The command should look like: ```node
../../../scripts/functional_test_runner
--config=test_suites/security_solution_endpoint/serverless.endpoint.config.ts```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
