## Summary
This PR fixes the areas where we display the Web Crawler naming bearing
in mind these agreements :
- We should be capitalizing when referring to the product name: Elastic
Web Crawler / Web Crawler /Elastic Open Web Crawler
- We can use lower case when referring to the feature or concept of web
crawler( crawler in short): "Use the web crawler to ..."
ESS:
ES3:
Notes: Also fixing buttons that take users to the Open Web Crawler repo
to open the links in a new tab and don't lose the product focus.
Fixes#199642
## Summary
~~This PR hides the role visibility dropdown in the new rule form when
in serverless.~~
This PR hides the role visibility dropdown in the new rule form **when
only one consumer is available**.
## How to test
1. Run Kibana security serverless and confirm the rules in stack
management do not have the role visibility dropdown.
2. Please also make sure that the drop-down still shows when
needed(outside of serverless).
## 📓 Summary
Closes#200900
As part of the readiness requirements to upgrade Kibana to v9.0.0, this
work deprecates some advanced settings that will be removed.
<img width="2568" alt="Screenshot 2024-11-21 at 11 15 25"
src="https://github.com/user-attachments/assets/81b9a8dc-6ad2-4646-9516-ed9a90d7bef2">
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
## 📓 Summary
Closes#200898
These changes deprecate some unused configurations and update the
implementation where required in preparation for the Kibana v9 upgrade.
<img width="3004" alt="Screenshot 2024-11-25 at 12 54 14"
src="https://github.com/user-attachments/assets/cfa56d25-a270-4ec5-a97a-e72e7a7478a4">
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
With this PR we move existing `parseEsqlQuery` method into a shared
security solution utils package. We need to the same functionality in
"SIEM migrations" feature. Previously we duplicated the code in [this
PR](https://github.com/elastic/kibana/pull/202331/files#diff-b5f1a952a5e5a9685a4fef5d1f5a4c3b53ce338333e569bb6f92ccf2681100b7R54)
and these are the follow-up changes to make parsing functionality shared
for easier re-use within security solution.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
PR fixes the issue reported by @dolaru when running stateful FTR
environment without docker setup locally:
```
info [es] killing node
info [es] stopping node scout
info [es] no debug files found, assuming es did not write any
info [es] cleanup complete
ERROR UNHANDLED ERROR
ERROR Error: Command failed with exit code 1: docker ps -a --format {{.Names}}
error during connect: Get "http://docker.example.com/v1.47/containers/json?all=1": command [ssh -o ConnectTimeout=30 -T -l dolaru -- debian-12-vm docker system dial-stdio] has exited with exit status 255, make sure the URL is valid, and Docker 18.09 or later is installed on the remote host: stderr=ssh: Could not resolve hostname dolaru-m2-mbp-debian.local: nodename nor servname provided, or not known
at makeError (/Users/dolaru/workspace/kibana/node_modules/execa/lib/error.js:60:11)
at handlePromise (/Users/dolaru/workspace/kibana/node_modules/execa/index.js:118:26)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at extractAndArchiveLogs (extract_and_archive_logs.ts:34:41)
at run_elasticsearch.ts:86:5
```
Since we don't need it for stateful ES instance, I added condition.
kbn-scout had the same issue, so I exported `cleanupElasticsearch` from
`kbn-test` to avoid code duplication
### Authz API migration for unauthorized routes
This PR migrates unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
--- EDIT ---
This PR also adds two privileges related to saved query APIs:
`savedQuery:read` and `savedQuery:manage`. These are given by default to
the same roles that already have access to the `query`-type saved
objects.
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
### What to do next?
1. Review the changes in this PR.
2. Elaborate on the reasoning to opt-out of authorization.
3. Routes without a compelling reason to opt-out of authorization should
plan to introduce them as soon as possible.
2. You might need to update your tests to reflect the new security
configuration:
- If you have snapshot tests that include the route definition.
## Any questions?
If you have any questions or need help with API authorization, please
reach out to the `@elastic/kibana-security` team.
---------
Co-authored-by: Lukas Olson <lukas@elastic.co>
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Marta Bondyra <4283304+mbondyra@users.noreply.github.com>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
## Summary
Upgrades references to webpack5 from v5.91.0 to v5.96.1
A v4 to v5 upgrade is being explored here:
https://github.com/elastic/kibana/pull/191106
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This adds exclusions for deprecated "rsa2elk" integration packages to Serverless projects.
The following packages should be excluded from Serverless.
- bluecoat
- cylance
- f5
- fortinet_forticlient
- juniper_junos
- juniper_netscreen
- netscout
- radware
- tomcat
---------
Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
## Summary
Closes#191939
Closes https://github.com/elastic/kibana/issues/175220
Adds various optimizations for the Trained Models page:
---
- Creates a new Kibana `/trained_models_list` endpoint responsible for
fetching complete data for the Trained Model UI page, including
pipelines, indices and stats.
Before the Trained Models page required 3 endpoints. The new
`trained_models_list` replaces them, reducing the overall latency.
<img width="715" alt="Screenshot 2024-12-02 at 16 18 32"
src="https://github.com/user-attachments/assets/34bebbdc-ae80-4e08-8512-199c57cb5b54">
---
- Optimized fetching of pipelines, indices and stats, reducing the
number of API calls to ES
Several issues with the old endpoint stemmed from the with_indices flag.
This flag triggered a method designed for the Model Map feature, which
involved fetching a complete list of pipelines, iterating over each
model, retrieving index settings multiple times, and obtaining both
index content and a full list of transforms.
The new endpoint solves these issues by fetching only the necessary
information for the Trained Model page with minimal calls to
Elasticsearch.
#### APM transaction with a new endpoint
<img width="1822" alt="image"
src="https://github.com/user-attachments/assets/55e4a5f0-e571-46a2-b7ad-5b5a6fc44ceb">
#### APM transaction with an old endpoint
https://github.com/user-attachments/assets/c9d62ddb-5e13-4ac1-9cbf-d685fbed7808
---
- Improves type definitions for different model types
### 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
## Summary
Part of https://github.com/elastic/kibana-team/issues/1082
Selects certain Sass files to replace with styles declared with Emotion.
This PR does not include any changes that would be noticeable by
end-users. It changes the internals to use a different technology for
styling components.
~~Some `className` attributes have been kept, because they are
referenced in JS and tests.~~ Update: all classNames that are no longer
needed for styling purposes have been removed.
* If the className was needed for tests, it has been replaced with a
test-subj.
* If the className was used as a selector in production code, it has
been replaced with alternative JS.
## References
1. https://emotion.sh/docs/globals
2. https://emotion.sh/docs/best-practices
3.
https://github.com/elastic/eui/discussions/6828#discussioncomment-10825360
---------
Co-authored-by: Jatin Kathuria <jatin.kathuria@elastic.co>
## Summary
This PR discontinues Reporting from having dual models for determining
the privilege to generate a report, and uses Kibana feature privileges
as the single model that controls those privileges.
### Changes
1. Removes all logic that is based on following settings:
* `xpack.reporting.roles.enabled`
* `xpack.reporting.roles.allow`
The settings are still supported, but any features that use the settings
are removed.
2. Removes the detection of the settings from the Upgrade Assistant
integration
### Release note
The default system of granting users the privilege to generate reports
has changed. Rather than assigning users the `reporting_user` role,
administrators should create a custom role that grants report-creation
privileges using Kibana application privileges.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
Correlates with https://elasticco.atlassian.net/browse/ES-9856: assign
the built-in `reporting_user` role the necessary Kibana application
privileges, and make the role not marked as deprecated.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Summary
This PR introduces two internal API routes:
1. `/internal/api/endpoint/workflow_isnights`
2. `/internal/api/endpoint/workflow_isnights/{insightId}`
### Details
- The first route (`/internal/api/endpoint/workflow_isnights`) will be
used with the `securityWorkflowInsightsService.fetch` method to retrieve
stored insights.
- The second route
(`/internal/api/endpoint/workflow_isnights/{insightId}`) will work with
the `securityWorkflowInsightsService.update` method to update existing
insights.
---------
Co-authored-by: Joey F. Poon <joey.poon@elastic.co>
This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.
## Context
In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.
***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***
WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.
In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.
It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.
### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.
## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Karen Grigoryan <karen.grigoryan@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
These are the followup updated to address feedback from my previous PRs:
* Make sure to use descriptive names specific to the `siem_migrations`
subdomain
([comment](https://github.com/elastic/kibana/pull/200978#pullrequestreview-2454582368)):
> Make sure you use descriptive names specific to the siem_migrations
subdomain. Names like RulesPage, RulesTable, useRulesColumns etc are way
too generic and conflict with the rule management terminology, which
would make code search more difficult.
* Export the memo component directly everywhere
([comment](https://github.com/elastic/kibana/pull/201597#discussion_r1858069127)):
> Could we export the memo component directly everywhere? It's shorter
and it makes it easier to find the references in the IDE.
* Use one hook to access APIs instead of two
([comment](https://github.com/elastic/kibana/pull/202494#discussion_r1867967135)):
> I see that for every API request we have to implement 2 separate
hooks. Why don't we add error handling to the same hook that does the
useQuery? so we have everything in one hook. Or is there a reason to
have them separate?
## Summary
Fixes https://github.com/elastic/kibana/issues/197650
Also fixes an issue where user has `cases: all ` and `edit case
settings: false`, user was able to edit settings.
Used `permissions.settings` instead of `permissions.update` and
`permissions.create` for custom fields and templates.
### How to test
- Verify by creating a user with different combinations of cases and
edit case settings privileges
### 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
## Summary
This PR adds example of tests, that doesn't meet deployment-agnostic
criteria. I also added steps explaining how to migrate existing tests to
DA.
## Summary
The ad-hoc task runner loads the `ad_hoc_run` saved object that contains
rule information when it first starts running. If the saved object
cannot be loaded due to saved object not found (likely because the SO
was deleted), the alerting event logger was throwing an error because it
didn't have the rule information to populate the `execute-backfill`
event. This PR fixes it so we're not throwing an error and writes the
`execute-backfill` event with whatever information is available.
## To Verify
1. Modify the ad-hoc task runner to load a random saved object
```
--- a/x-pack/plugins/alerting/server/task_runner/ad_hoc_task_runner.ts
+++ b/x-pack/plugins/alerting/server/task_runner/ad_hoc_task_runner.ts
@@ -294,7 +294,8 @@ export class AdHocTaskRunner implements CancellableTask {
const adHocRunSO: SavedObject<AdHocRunSO> =
await this.context.encryptedSavedObjectsClient.getDecryptedAsInternalUser<AdHocRunSO>(
AD_HOC_RUN_SAVED_OBJECT_TYPE,
- adHocRunParamsId,
+ `abcdefgh`,
+ // adHocRunParamsId,
{ namespace }
```
2. Create a detection rule and then schedule backfill run for it. You
should see the execution fail with `Executing ad hoc run with id
\"7401d1f1-73fc-4483-acd5-edf6180028ce\" has resulted in Error: Saved
object [ad_hoc_run_params/abcdefgh] not found` but you should NOT see
any errors from task manager like `Task ad_hoc_run-backfill
"40fd4c52-411f-462c-b285-87e33520bd5b" failed: Error:
AlertingEventLogger not initialized`
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
As part of https://github.com/elastic/kibana/issues/200799, this PR
removes filter (previously the filter was based on any group by field,
which was changed to focus only on `service.name` for kubecon demo) so
that all events are shown on events timeline.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Faisal Kanout <faisal.kanout@elastic.co>
