-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Security Solution] Support bundling ESS and Serverless OAS separately #184348
[Security Solution] Support bundling ESS and Serverless OAS separately #184348
Conversation
c4602b8
to
712732f
Compare
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
Pinging @elastic/security-solution (Team: SecuritySolution) |
Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed during tech time, let's try to implement the includeLabels
filter for the generator and make this setting required.
Discussed complexity of DetailsFor example there is a following document tree (represented as a binary tree for simplicity) where one of the second level node (root level is one, the next below it is two) is labeled by Having labels at the concrete level (Operation object) helps to significantly simplify the implementation. |
bdc76ef
to
426976f
Compare
Discussion on whether |
426976f
to
c3b58ce
Compare
c3b58ce
to
324f2e4
Compare
@maximpn What will be the default behavior if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @maximpn, I left a few suggestions and concerns. I think the implementation has a minor bug, and there's a few things to improve. Otherwise, overall it looks really good!
packages/kbn-openapi-bundler/src/__test__/include_labels.test.ts
Outdated
Show resolved
Hide resolved
...ges/kbn-openapi-bundler/src/bundler/process_document/document_processors/include_x_labels.ts
Outdated
Show resolved
Hide resolved
...ges/kbn-openapi-bundler/src/bundler/process_document/document_processors/include_x_labels.ts
Outdated
Show resolved
Hide resolved
...rebuilt_rules_and_timelines_status/get_prebuilt_rules_and_timelines_status_route.schema.yaml
Outdated
Show resolved
Hide resolved
...rebuilt_rules_and_timelines_status/get_prebuilt_rules_and_timelines_status_route.schema.yaml
Outdated
Show resolved
Hide resolved
324f2e4
to
df57d9f
Compare
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]
History
To update your PR or re-run it, just comment with: cc @maximpn |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maximpn LGTM, thank you for the fixes ✅
**Epic:** elastic/security-team#9693 (internal) **Partially addresses:** elastic/entity-analytics#60 (internal) ## Summary This PR fixes a few issues with the existing OpenAPI schemas for the Entity Analytics API based on findings described in elastic/entity-analytics#60 and the recent developments of the [OpenAPI specs bundler](elastic/security-team#9401): - [x] Thanks to #184348, now we can mark endpoints as being available in ESS, Serverless, or both offerings by marking them with `x-labels`. - [x] We can also explicitly mark internal endpoints with `x-internal: true`. While this is not required when the endpoint's path starts with `/internal`, I think it's still good to mark them explicitly, according to `access` modifier in the route registration. This fixed an issue where a couple of endpoints, while being in fact internal, were included in the OAS bundle because their paths do not start with `/internal`: `/api/risk_scores/calculation`, `/api/risk_scores/calculation/entity`, `/engine/settings`, `/engine/status`. - [x] Specified correct paths for `/internal/risk_score/engine/settings` and `/internal/risk_score/engine/status` endpoints. ## How to test Run the bundler: ```sh cd x-pack/plugins/security_solution yarn openapi:bundle ``` Check that the OpenAPI bundles located under the `x-pack/plugins/security_solution/target/openapi` folder don't contain any Entity Analytics endpoints or components.
…API (#187261) 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 #184348
Resolves: https://github.com/elastic/security-team/issues/9516
Summary
As a part of Serverless API reference documentation effort we need to have an ability to produce independent Serverless and ESS OpenAPI specification (OAS) bundles. This PR addresses this issue by adding a new custom property
x-labels
(applicable to OAS operation objects) representing an array of strings and bundling configuration option to exclude anything marked with specific labels.How does it work?
Added functionality allows to mark OAS operation object (objects defined under an API endpoint path as a HTTP method like
get
,post
and etc) with arbitrary labels by usingx-labels
custom property like in an example belowThis labelling DOESN'T change produced bundle by itself. It's required to use bundler's
includeLabels
option to include API endpoint operation object(s).includeLabels
accepts a list of labels. An operation object is included when it has a label matching labels passed toincludeLabels
. In mathematical terms operation object's labels set intersects withincludeLabels
.How to use it for producing separate Serverless and ESS bundles?
get
orpost
) withx-labels
custom property.An example below has all operation objects under
/api/some_path
path labeled withess
label as well as operation objects under/api/another_path
path. On top of thatGET /api/another_path
hasserverless
label as well.options.includeLabels
is responsible for including document nodes labeled with specific labels. You need two bundler invocations with differentoptions.includeLabels
values like belowIt will produce two following bundles
(1) for Serverless
and (2) for ESS
You may notice (2) has everything included since each operation object is labeled with
ess
label.