-
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] Add missing alerts (signals) API endpoints OpenAPI specs #184838
Conversation
6a3688a
to
54c379b
Compare
Hey @marcelhallmann, Could you check added OpenAPI specs for correctness? Don't pay too much attention to summaries and descriptions since it will be further refined in #183702. I used some information from the documentation page. |
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) |
Pinging @elastic/security-detection-engine (Team:Detection Engine) |
54c379b
to
68e7e95
Compare
paths: {} | ||
components: | ||
schemas: | ||
GenericErrorResponse: |
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.
I was confused here at first because the SiemResponseFactory
uses status_code
(https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/server/lib/detection_engine/routes/utils.ts#L184) and message as the response if we throw during the executor and return a 500. Can we add a response schema for the siemResponse
as well, and maybe rename this one to PlatformErrorResponse
?
conflicts: z.enum(['abort', 'proceed']).optional().default('abort'), | ||
}) | ||
.merge( | ||
z.union([ |
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.
There's a type error here, can't merge a zod union with another object
}); | ||
|
||
export type CreateAlertsMigrationResponse = z.infer<typeof CreateAlertsMigrationResponse>; | ||
export const CreateAlertsMigrationResponse = z.object({ |
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.
The migration response can have an error as part of the ok
response: https://github.com/elastic/kibana/blob/main/x-pack/plugins/security_solution/server/lib/detection_engine/routes/signals/create_signals_migration_route.ts#L142
Looks like this response should be a union of the error and regular responses
|
||
export type CleanupAlertsMigrationRequestBody = z.infer<typeof CleanupAlertsMigrationRequestBody>; | ||
export const CleanupAlertsMigrationRequestBody = z.object({ | ||
migration_ids: z.array(z.string()).min(1).optional(), |
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.
This should be required
message: z.string().optional(), | ||
status_code: z.number().int().optional(), |
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.
message
and status_code
within error
are not optional, though error
is optional
tags: | ||
- Alerts migration API | ||
parameters: | ||
- name: from |
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.
I don't see the codegen for this parameter?
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.
It turns out request response types aren't generated when x-codegen-enabled
is omitted but schemas are generated for common schemas. Since a valid spec may produce invalid code I explicitly added x-codegen-enabled: true
.
index: NonEmptyString.optional(), | ||
version: z.number().int().optional(), | ||
signal_versions: z.array(AlertVersion).optional(), | ||
migrations: z.array(MigrationStatus).optional(), | ||
is_outdated: z.boolean().optional(), |
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.
Every field is required
|
||
export type GetAlertsMigrationStatusResponse = z.infer<typeof GetAlertsMigrationStatusResponse>; | ||
export const GetAlertsMigrationStatusResponse = z.object({ | ||
indices: z.array(IndexMigrationStatus).optional(), |
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.
indices
is required
version: z.number().int().optional(), | ||
count: z.number().int().optional(), |
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.
These are required
id: NonEmptyString.optional(), | ||
status: z.enum(['success', 'failure', 'pending']).optional(), | ||
version: z.number().int().optional(), | ||
updated: z.string().datetime().optional(), |
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.
All required
b5ac814
to
6952fc1
Compare
@marshallmain thank you for the review! I addressed your comments and also found a few things to fix. Explicitly enabled code generation via |
6759a2e
to
25db960
Compare
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.
Looks much better, thanks for addressing the comments. I only see one remaining issue.
migration_id: z.string(), | ||
migration_index: z.string(), |
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.
To match the API route behavior these should exist but be null
for the error and skipped migration cases.
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.
OAS doesn't provide a way to specify explicit null
fields. There is a nullable
modifier which marks a type as nullable. In this particular case it's possible to declare a single response type instead of AlertsIndexMigrationSuccess
, AlertsIndexMigrationError
and SkippedAlertsIndexMigration
with migration_id
and migration_index
being string or null. Such schema won't describe the response precisely neither.
What's the approach you expect here?
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.
We discussed on slack and the approach is ok as is. Better to leave the properties out of the response schema than have them typed incorrectly or make the rest of the schema less precise.
26a8c52
to
a6e7e34
Compare
a6e7e34
to
5ace3d8
Compare
5ace3d8
to
9ffe520
Compare
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.
👍
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Module Count
Async chunks
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.
Rule Management changes LGTM 👍
I did a high-level review of the whole diff and checked the changes owned by our team.
Can we please add the new folders to the CODEOWNERS file in a separate PR?
…I specs (elastic#184838) **Addresses:** elastic#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.
Addresses: #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