## Summary
* Create new API `/internal/risk_score/engine/schedule_now`
* Fix storybook, it was broken due to some mock changes
* Update status API to return task status
* Add schedule risk engine panel to bulk asset criticality final step
### How to test it?
* Enable asset criticality in stack management / Advanced settings
* Enable the risk engine
* Open the asset criticality page inside the Manage section
* Upload a valid file
* Verify that the new panel is present and that you can schedule the
risk engine run by pressing the button
### Checklist
Delete any items that are not applicable to this PR.
- [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
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [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>
Co-authored-by: Mark Hopkin <mark.hopkin@elastic.co>
Co-authored-by: natasha-moore-elastic <137783811+natasha-moore-elastic@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Resolves https://github.com/elastic/security-docs-internal/issues/37 by
improving the Endpoint management API docs content. Adds missing and
improves existing operation summaries and operation descriptions to
adhere to our [OAS
standards](450494532/API+reference+docs).
**Note**: Couldn’t add descriptions for the following operations, since
they’re not documented in [ESS API
docs](https://www.elastic.co/guide/en/security/8.15/management-api-overview.html):
- POST /api/endpoint/protection_updates_note/{package_policy_id}
- GET /api/endpoint/protection_updates_note/{package_policy_id}
- GET /api/endpoint/policy/summaries
- GET /api/endpoint/policy_response
- POST /api/endpoint/suggestions/{suggestion_type}
- GET /api/endpoint/metadata
- GET /api/endpoint/metadata/{id}
- GET /api/endpoint/metadata/transforms
---------
Co-authored-by: Ash <1849116+ashokaditya@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Addresses:** https://github.com/elastic/kibana/issues/190035
## Summary
This PR fixes `operationId` conflicts in Security Solution OpenAPI specs.
## Details
API reference documentation platform (Bump.sh) expects unique `operationId`s to build proper navigation on the documentation page. It's expected each `operationId` throughout whole Kibana since Kibana API reference documentation will contain all available API endpoints.
## Summary
Updates/Adds Open API specs for existing public Endpoint APIs. The PR
includes deperated API schemas as well but we can remove them if we all
agree to it.
Note: The PR doesn't change existing kibana schemas that is used in our
server routes and most of the changes in here are file moves and
updating imports to unify duplicate naming/import. This to ensure that
we can easily maintain the open api specs going forward. The best way to
review this is by looking at commits. The major moving cleaning up
happens after commit names prefixed with **_refactor_** or
`645fbc0f1d` and onwards. I would also
suggest hiding whitespaces when reviewing via Github.
closes elastic/kibana/issues/183816
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
### 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Resolves: https://github.com/elastic/kibana/issues/187647**
## Summary
Added a new API endpoint `POST
/internal/detection_engine/prebuilt_rules/_bootstrap`. This endpoint is
responsible for installing the necessary packages for prebuilt detection
rules to function properly. This allows us to avoid calling Fleet
directly from FE and helps encapsulate complex logic of the package
version selection in a single place on the backend.
Currently, it installs or upgrades (if already installed) two packages:
`endpoint` and `security_detection_engine`.
The response looks like this:
```json5
{
packages: [
{
name: 'detection_engine',
version: '1.0.0',
status: 'installed',
},
{
name: 'endpoint',
version: '1.0.0',
status: 'already_installed',
},
],
}
```
We call this endpoint from Kibana every time a user lands on any
security solution page. The endpoint checks if the required packages are
missing or if a newer version is available. If so, the newer version is
installed, and the package status will be `installed` in the response.
If all packages are up-to-date, the package status will be
`already_installed` in the response. This allows us to invalidate
prebuilt rule endpoints more efficiently and avoid sending extra
requests from Kibana:
```ts
if (
response?.packages.find((pkg) => pkg.name === PREBUILT_RULES_PACKAGE_NAME)?.status === 'installed'
) {
// Invalidate other pre-packaged rules related queries. We need to do
// that only if the prebuilt rules package was installed, indicating
// that there might be new rules to install.
invalidatePrePackagedRulesStatus();
invalidatePrebuiltRulesInstallReview();
invalidatePrebuiltRulesUpdateReview();
}
```
The performance gain is that we do not invalidate prebuilt rules when
the package is already installed.
Previously:
`Fetch rules initially -> Upgrade rules package -(always)-> Re-fetch
rules`
Now:
`Fetch rules initially -> Upgrade rules package -(only if there's a new
package version)-> Re-fetch rules`
This will result in fewer redundant API requests from Kibana.
**Relates to:** https://github.com/elastic/kibana/issues/183661 (internal)
**Relates to:** https://github.com/elastic/kibana/issues/183821 (internal)
**Relates to:** https://github.com/elastic/kibana/issues/183837 (internal)
## Summary
It addresses a discussion Rule Management team had on a tech time meeting whose outcome was usage of consistent operationId, files and folder naming related to OpenAPI specs. For example use `Read` instead of `Get` since it gives better readability and matches with already used approach.
This PR aligns the naming and performs necessary renaming.
## Summary
Add return types to all of our route handlers.
Before we did things like this in _some_ APIs:
```
const resBody: CreateAssetCriticalityRecordResponse = { blah : 'blah'};
```
And I have moved to this style:
```
async (
context,
request,
response
): Promise<IKibanaResponse<CreateAssetCriticalityRecordResponse>> => {
```
This keeps the API docs in sync, I saw that this is how they do it in
the elastic assistant plugin and liked it. I think it is clearer to have
this stuff in the route definition, near the URL and request validation.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
**Addresses**: https://github.com/elastic/kibana/issues/184428
## Summary
This PR adds scripts for automatic bundling of Timeline API OpenAPI
specs as a part of PR pipeline. Corresponding result bundles are
automatically committed to the Security Solution plugin
`x-pack/plugins/security_solution` in the `docs/openapi/ess/` and
`docs/openapi/serverless` folders (similar to
https://github.com/elastic/kibana/pull/186384).
---------
Co-authored-by: Jan Monschke <jan.monschke@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
**Addresses**: https://github.com/elastic/kibana/issues/184428
## Summary
This PR adds scripts for automatic bundling of Entity Analytics API OpenAPI specs as a part of PR pipeline. Corresponding result bundles are automatically committed to the Security Solution plugin `x-pack/plugins/osquery` in the `docs/openapi/ess` and `docs/openapi/serverless` folders (similar to https://github.com/elastic/kibana/pull/186384).
**Relates to:** https://github.com/elastic/security-team/issues/9401
## Summary
Disabling OpenAPI spec linting in https://github.com/elastic/kibana/pull/179074 lead to accumulating invalid OpenAPi specs.
This PR enables OpenAPI linting for Security Solution plugin and make appropriate fixes to make the linting pass.
## Details
OpenAPI linting is a part of code generation. It runs automatically but can be disabled via `skipLinting: true`. Code generation with disabled linting isn't able to catch all possible problems in processing specs.
The majority of problems came from Entity Analytics and Osquery OpenAPI specs. These specs were fixed and refactored to enable code generation and integrate generated artefacts into routes to make sure OpenAPI spec match API endpoints they describe. It helped to catch some subtle inconsistencies.
**Addresses:** https://github.com/elastic/kibana/issues/183661
## Summary
This PR adds missing OpenAPI specs for the following Detections API endpoints available in both Serverless and ESS
- `POST /api/detection_engine/rules/preview`
and the following API endpoints available in ESS only
- `GET /api/detection_engine/privileges`
- `POST /api/detection_engine/rules/_bulk_delete`
This PR adds OpenAPI schemas for Defend Workflows API endpoints that
previously didn't have them. Here are the changes made:
1. Added a schema for `/api/endpoint/isolate`, which is deprecated and
now redirects as a `308` to the new path
(`/api/endpoint/action/isolate`). It's tagged with `x-labels` as `ess`
only.
2. Added a schema for `/api/endpoint/unisolate`, which is deprecated and
now redirects as a `308` to the new path
(`/api/endpoint/action/unisolate`). It's tagged with `x-labels` as `ess`
only.
3. Added a schema for
`/api/endpoint/protection_updates_note/{package_policy_id}`.
4. Added `x-labels` field to all existing Defend Workflows API paths for
proper tagging.
For more information on `x-labels`, please refer to
https://github.com/elastic/kibana/pull/184348
**Addresses:** https://github.com/elastic/kibana/issues/183661
## Summary
This PR adds missing OpenAPI specs for the Alert Index API endpoints available in ESS
- `POST /api/detection_engine/index`
- `GET /api/detection_engine/index`
- `DELETE /api/detection_engine/index`
**Addresses:** https://github.com/elastic/kibana/issues/183661
## Summary
This PR adds missing OpenAPI specs for the following API endpoints (Alerts API and Alerts Migration API) available in both Serverless and ESS
- `POST /api/detection_engine/signals/status`
- `POST /api/detection_engine/signals/tags`
- `POST /api/detection_engine/signals/search`
and API endpoints available only in ESS
- `POST /api/detection_engine/signals/migration_status`
- `POST /api/detection_engine/signals/migration`
- `POST /api/detection_engine/signals/finalize_migration`
- `DELETE /api/detection_engine/signals/migration`
**Note:** Code generation is enabled for the added specs to verify that it works and produces expected results. Generated Zod schemas and types aren't integrated in the route's code.
## Summary
This PR moves disclaimer comment section to the top of the generated
files to support `import/order` ESlint rule.
## Details
`kbn-openapi-generator` generates `<schema-name>.gen.ts` files for each
encountered schema with enabled code generation. The generate file
contains imports of the referenced schema from the other generated
files. Everything works until there is a reference to a package or
another plugin. Consider an example below where we have a generated file
with an import from `kbn-openapi-common` package (this package doesn't
exist in reality and used for clarity but the same can be shown with
cross plugin references)
```ts
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
* or more contributor license agreements. Licensed under the Elastic License
* 2.0; you may not use this file except in compliance with the Elastic License
* 2.0.
*/
import { z } from 'zod';
/*
* NOTICE: Do not edit this file manually.
* This file is automatically generated by the OpenAPI Generator, @kbn/openapi-generator.
*
* info:
* title: Shared Alert Primitives Schema
* version: not applicable
*/
import { NonEmptyString } from '@kbn/openapi-common/primitives';
/**
* A list of alerts ids.
*/
export type AlertIds = z.infer<typeof AlertIds>;
export const AlertIds = z.array(NonEmptyString).min(1);
```
If `import/order` rule is enabled for this file linting with fixing will
fail with an error `8:1 error There should be no empty line within
import group import/order` since auto-fix can't fix the file due to the
comment between imports. Linting with auto-fixing is a part of code
generation process which means code generation will fail in that case.
For example lists plugin has `import/order` rule enabled.
The problem is fixed by moving disclaimer (NOTICE) section to the top
just right above the first import. Since the whole file is
auto-generated it makes sense.
While the Rules Management team was researching current status of OpenAPI migration in Security Solution, they found two of our endpoints that are /internal/... but marked as access:public. Updating the routes to be as intended - access: internal.
## Summary
- Extended the code generation package to allow for bundling of OpenAPI
specifications before passing them to a template. Here's an example of
how the new `bundle` option can be used:
```ts
await generate({
title: 'API client for tests',
rootDir: SECURITY_SOLUTION_ROOT,
sourceGlob: './**/*.schema.yaml',
templateName: 'api_client_supertest',
skipLinting: true,
bundle: {
outFile: join(REPO_ROOT,
'x-pack/test/api_integration/services/security_solution_api.gen.ts'),
},
})
```
- Added a new template
(`packages/kbn-openapi-generator/src/template_service/templates/api_client_supertest.handlebars`)
that allows to generate an API client to be used in integrational tests.
The template outputs a collection of all Security Solution APIs that is
later added to `FtrProviderContext` for easy access in test files.
- The generated client is located in
`x-pack/test/api_integration/services/security_solution_api.gen.ts`
- It is now used in some detection engine API integration tests.
Before:
```ts
const { body } = await supertest
.post(DETECTION_ENGINE_RULES_URL)
.set('kbn-xsrf', 'true')
.set(ELASTIC_HTTP_VERSION_HEADER, '2023-10-31')
.send(rule)
.expect(200);
```
After:
```ts
const securitySolutionApi = getService('securitySolutionApi');
const { body } = await securitySolutionApi.createRule({ body: rule
}).expect(200);
```
- All API methods of the generated client now have correct types defined
for body, query, and param arguments
