-
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
[Cloud Security] Alerts Preview Contextual Flyout #197102
[Cloud Security] Alerts Preview Contextual Flyout #197102
Conversation
/ci |
Pinging @elastic/kibana-cloud-security-posture (Team:Cloud Security) |
x-pack/packages/kbn-cloud-security-posture/common/utils/helpers.ts
Outdated
Show resolved
Hide resolved
x-pack/packages/kbn-cloud-security-posture/common/utils/helpers.ts
Outdated
Show resolved
Hide resolved
x-pack/packages/kbn-cloud-security-posture/common/utils/helpers.ts
Outdated
Show resolved
Hide resolved
...ns/security_solution/public/cloud_security_posture/components/alerts/alerts_preview.test.tsx
Show resolved
Hide resolved
@@ -0,0 +1,125 @@ | |||
/* |
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 think we shouldn't be the owners of this component, it has nothing to do with Cloud Security Posture. I understand that this is the outcome of this unclear ownership, but I would try to find a more suitable place for the alerts component. @PhilippeOberti wdyt about the code ownership? right now it's a bit like "who wrote the code owns it", but I don't think it is a good idea longer term
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.
yeah it's a bit tricky... While I agree that the logic isn't related to Cloud Security, if the component is only used within another component owned by Cloud Security it's difficult for other teams to know how to properly test it (where it is, how to generate data to have things show correctly...).
A few times I've had situation where I didn't even know that one of our components was used by another team and didn't test things when I made changes to it...
Also, if that component is only used in one place, it's hard to justify having us own it. What if we need to make changes to it? We would still need a way to have you guys review it to make sure we don't brake your functionality?
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.
on the other side, we are the ones that are supposed to know how this thing works, so I totally get your point of us owning it. I just feel like if we want to do this, we then need to have a good look at it before it's being merged to make sure we understand what it does, we should have a say on how it's being written and place it in a folder that makes sense
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.
yeah, let's discuss it in the sync as proposed. Right now we have the situation that we've built misconfig, vuln and alert previews on the entity flyout and you folks built the same but on document flyout. For me the ideal situation would be to split the ownership by the business domain: we own everything related to cloud security (misconfiguration and vulnerability) and alerts should be owned by the team owning the business domain of alerts. Which team is the owner of the alerts logic in the Security Org is unclear to me tbh. But if we continue to own based on who wrote the code, we have the risk of things being broken (no necessarily technically but rather in business sense) without the owners of the domain logic realising that
...plugins/security_solution/public/cloud_security_posture/components/alerts/alerts_preview.tsx
Outdated
Show resolved
Hide resolved
...plugins/security_solution/public/cloud_security_posture/components/alerts/alerts_preview.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/cloud_security_posture/components/entity_insight.tsx
Outdated
Show resolved
Hide resolved
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.
most of the logic lgtm, some additional comments to make the code cleaner and more error prone
...ns/security_solution/public/cloud_security_posture/components/alerts/alerts_preview.test.tsx
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,125 @@ | |||
/* |
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.
yeah, let's discuss it in the sync as proposed. Right now we have the situation that we've built misconfig, vuln and alert previews on the entity flyout and you folks built the same but on document flyout. For me the ideal situation would be to split the ownership by the business domain: we own everything related to cloud security (misconfiguration and vulnerability) and alerts should be owned by the team owning the business domain of alerts. Which team is the owner of the alerts logic in the Security Org is unclear to me tbh. But if we continue to own based on who wrote the code, we have the risk of things being broken (no necessarily technically but rather in business sense) without the owners of the domain logic realising that
x-pack/plugins/security_solution/public/cloud_security_posture/components/entity_insight.tsx
Outdated
Show resolved
Hide resolved
|
||
const severityMap = new Map<string, number>(); | ||
|
||
(['open', 'acknowledged'] as AlertsByStatus[]).forEach((status) => { |
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.
you don't need this piece of logic here as you filter out closed
in the entity insight. So the component can be free of knowing about different statuses
}); | ||
|
||
const filteredAlertsData: ParsedAlertsData = alertsData | ||
? Object.fromEntries(Object.entries(alertsData).filter(([key]) => key !== 'closed')) |
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.
let's use FILTER_CLOSED
from x-pack/plugins/security_solution/common/types/index.ts
</TestProviders> | ||
); | ||
|
||
// there should be 3 element with this id because we have 3 different severities in this test |
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.
nit: let's change the test case name to reflect that instead of a comment
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.
Look good! Just a few minor comments.
alertsTotal, | ||
euiTheme, | ||
}: { | ||
alertsTotal: string | number; |
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.
Can this truly be a string
? We can use only a number instead of a union.
css={css` | ||
font-weight: ${euiTheme.font.weight.semiBold}; | ||
`} |
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.
css={css` | |
font-weight: ${euiTheme.font.weight.semiBold}; | |
`} | |
css={{ | |
fontWeight: euiTheme.font.weight.semiBold, | |
}} | |
> |
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
History
|
Starting backport for target branches: 8.x |
## Summary <img width="1447" alt="Screenshot 2024-10-21 at 10 38 49 PM" src="https://github.com/user-attachments/assets/e7d011dd-8245-4bf8-ad96-a4fd634e82c1"> This PR is for Alerts preview component in Contextual Flyout (Host Name) (cherry picked from commit 675b54b)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
# Backport This will backport the following commits from `main` to `8.x`: - [[Cloud Security] Alerts Preview for Host Name (#197102)](#197102) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Rickyanto Ang","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-13T18:10:11Z","message":"[Cloud Security] Alerts Preview for Host Name (#197102)\n\n## Summary\r\n<img width=\"1447\" alt=\"Screenshot 2024-10-21 at 10 38 49 PM\"\r\nsrc=\"https://github.com/user-attachments/assets/e7d011dd-8245-4bf8-ad96-a4fd634e82c1\">\r\n\r\n\r\nThis PR is for Alerts preview component in Contextual Flyout (Host Name)","sha":"675b54bee70142f03929391d36c724e0f5223196","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","Team:Cloud Security","backport:prev-minor","v8.17.0"],"title":"[Cloud Security] Alerts Preview for Host Name","number":197102,"url":"https://github.com/elastic/kibana/pull/197102","mergeCommit":{"message":"[Cloud Security] Alerts Preview for Host Name (#197102)\n\n## Summary\r\n<img width=\"1447\" alt=\"Screenshot 2024-10-21 at 10 38 49 PM\"\r\nsrc=\"https://github.com/user-attachments/assets/e7d011dd-8245-4bf8-ad96-a4fd634e82c1\">\r\n\r\n\r\nThis PR is for Alerts preview component in Contextual Flyout (Host Name)","sha":"675b54bee70142f03929391d36c724e0f5223196"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/197102","number":197102,"mergeCommit":{"message":"[Cloud Security] Alerts Preview for Host Name (#197102)\n\n## Summary\r\n<img width=\"1447\" alt=\"Screenshot 2024-10-21 at 10 38 49 PM\"\r\nsrc=\"https://github.com/user-attachments/assets/e7d011dd-8245-4bf8-ad96-a4fd634e82c1\">\r\n\r\n\r\nThis PR is for Alerts preview component in Contextual Flyout (Host Name)","sha":"675b54bee70142f03929391d36c724e0f5223196"}},{"branch":"8.x","label":"v8.17.0","branchLabelMappingKey":"^v8.17.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Rickyanto Ang <[email protected]>
## Summary <img width="1447" alt="Screenshot 2024-10-21 at 10 38 49 PM" src="https://github.com/user-attachments/assets/e7d011dd-8245-4bf8-ad96-a4fd634e82c1"> This PR is for Alerts preview component in Contextual Flyout (Host Name)
## Summary <img width="1447" alt="Screenshot 2024-10-21 at 10 38 49 PM" src="https://github.com/user-attachments/assets/e7d011dd-8245-4bf8-ad96-a4fd634e82c1"> This PR is for Alerts preview component in Contextual Flyout (Host Name)
…ment details flyout (#200268) ## Summary This PR made some changes to the alert count API in document details flyout. Closed alerts are now removed when showing total count and distributions. Data fetching logic is updated to match the one used in host flyout (#197102). Notable changes: - Closed alerts are now excluded - Number of alerts in alerts flyout should match the ones in host flyout - Clicking the number will open timeline with the specific entity and `NOT kibana.alert.workflow_status: closed` filters - If a host/user does not have active alerts (all closed), no distribution bar is shown https://github.com/user-attachments/assets/3a1d6e36-527e-4b62-816b-e1f4de7314ca ### 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
…ment details flyout (elastic#200268) ## Summary This PR made some changes to the alert count API in document details flyout. Closed alerts are now removed when showing total count and distributions. Data fetching logic is updated to match the one used in host flyout (elastic#197102). Notable changes: - Closed alerts are now excluded - Number of alerts in alerts flyout should match the ones in host flyout - Clicking the number will open timeline with the specific entity and `NOT kibana.alert.workflow_status: closed` filters - If a host/user does not have active alerts (all closed), no distribution bar is shown https://github.com/user-attachments/assets/3a1d6e36-527e-4b62-816b-e1f4de7314ca ### 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 (cherry picked from commit a37a02e)
@animehart How can I test this? |
…ment details flyout (elastic#200268) ## Summary This PR made some changes to the alert count API in document details flyout. Closed alerts are now removed when showing total count and distributions. Data fetching logic is updated to match the one used in host flyout (elastic#197102). Notable changes: - Closed alerts are now excluded - Number of alerts in alerts flyout should match the ones in host flyout - Clicking the number will open timeline with the specific entity and `NOT kibana.alert.workflow_status: closed` filters - If a host/user does not have active alerts (all closed), no distribution bar is shown https://github.com/user-attachments/assets/3a1d6e36-527e-4b62-816b-e1f4de7314ca ### 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 is for Alerts preview component in Contextual Flyout