-
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] [Sourcerer] Update to use Kibana Data Views #111461
Conversation
x-pack/plugins/security_solution/public/common/components/top_n/selectors.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/common/components/url_state/initialize_redux_by_url.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/common/containers/source/index.tsx
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/common/containers/source/index.tsx
Outdated
Show resolved
Hide resolved
const { id, ...rest } = defaultDataView; | ||
if (id === null) { | ||
// if id is null, rest is error | ||
addError(rest, { |
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 am wondering if we can use internal kibana user to create this data view instead of a super user
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 talked to @stephmilovic and we are using the saved object client from our route's context to create our data view and that's why we need to do it like that. I do think that we need a different splash screen to tell user that they do not have the right to create this dataview
path: [ALERTS_PATH, `${RULES_PATH}/id/:id`, `${UEBA_PATH}/:id`], | ||
): SourcererScopeName.default | SourcererScopeName.detections => | ||
matchPath(pathname, { | ||
path: [ALERTS_PATH, RULES_PATH, `${RULES_PATH}/:anything`, `${UEBA_PATH}/:id`], |
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 just wanted to do that on the rule details page
x-pack/plugins/security_solution/public/common/store/sourcerer/helpers.ts
Outdated
Show resolved
Hide resolved
@@ -27,9 +28,14 @@ export interface ManageScope { | |||
docValueFields: DocValueFields[]; | |||
errorMessage: string | null; | |||
id: SourcererScopeName; | |||
// the index pattern value passed to the search to make the query | |||
// includes fields and a title with active index names | |||
indexPattern: IIndexPattern; |
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 feel like we should no have anymore IIndexPattern
since it is deprecated and use DataviewSpec
.Maybe in another follow up PR
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.
)} | ||
/> | ||
</EuiFlexItem> | ||
<StyledFullHeightContainer onKeyDown={onKeyDown} ref={containerElement}> |
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 do not understand what you mean here, I think it is still possible that user does not have any alert index created in this page. I think you are on something here but I will like to brainstorm.
@elasticmachine merge upstream |
Closing in favor of: #114806 |
💔 Build Failed
Failed CI StepsTest FailuresKibana Pipeline / general / User sec_all_user with role(s) sec_all_role can create a case.Cases privileges User sec_all_user with role(s) sec_all_role can create a caseStack Trace
Kibana Pipeline / general / User sec_read_cases_all_user with role(s) sec_read_cases_all_role can create a case.Cases privileges User sec_read_cases_all_user with role(s) sec_read_cases_all_role can create a caseStack Trace
Kibana Pipeline / general / User sec_all_user with role(s) sec_all_role can create a case.Cases privileges User sec_all_user with role(s) sec_all_role can create a caseStack Trace
and 1 more failures, only showing the first 3. Metrics [docs]Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
References to deprecated APIs
History
To update your PR or re-run it, just comment with: |
Kibana
Index PatternsData Views & Runtime Fields in Security Solution SourcererIssue: https://github.com/elastic/security-team/issues/772
security-solution
Kibana data viewrequestIndexFieldSearch
in timelines to take adataViewId
pick_events.tsx
)dataViewId
property to timeline, stored inreferences
on the saved objectQuirks
index.indexOf(signalIndexName) === 0
instead ofindex === signalIndexName
auditbeat-*,auditbeat-*,auditbeat-*,auditbeat-*
andauditbeat-*,auditbeat-*
are both valid. We're only going to allow them to select one instance of auditbeat from our combo box, but the select needs the full name so the user can distinguish between the data views and know where they put their runtime fieldssecuritySolution:defaultIndex
. A page refresh is required for updates to take placesecurity-solution
data view. on initial app load, or if the signals index gets deleted, signalIndexName is null and quickly set. We have a call to update thesecurity-solution
data view when the signalIndexName is updatedesClient.fieldCaps
instead ofesClient.search
oresClient.count
as both of those methods require there to be data on the index pattern. When.siem-signals-default
is initially created, it will not immediately have data. So usingesClient.fieldCaps
will tell us if the index exists even without dataUI Updates coming in a follow up PR. See Monina's excellent design direction in the original issue: https://github.com/elastic/security-team/issues/772
Sourcerer Updates to KIP/Data Views:
Runtime Fields in Security Solution:
Checklist