Skip to content
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

Closed
wants to merge 183 commits into from

Conversation

stephmilovic
Copy link
Contributor

@stephmilovic stephmilovic commented Sep 7, 2021

Kibana Index Patterns Data Views & Runtime Fields in Security Solution Sourcerer

Issue: https://github.com/elastic/security-team/issues/772

  • Removes config index patterns and only use Kibana index patterns. Create a special security-solution KIP from the config index patterns. PR Reviewed: [Security Solution] [Sourcerer] KIP Feature Branch Kickoff, remove config index patterns #106460
  • Changes to the config index patterns to update the security-solution Kibana data view
  • Add signals index to default Kibana data view
  • Updates requestIndexFieldSearch in timelines to take a dataViewId
  • Switch to get fields directly from Kibana data view
  • Enable sourcerer to break up indices on each Kibana data view once selected
  • Update timeline sourcerer ui (pick_events.tsx)
  • Add dataViewId property to timeline, stored in references on the saved object

Quirks

  • the siem signals index needs to have a wildcard in the data view, but not in the security solution. The result is using strange checks like index.indexOf(signalIndexName) === 0 instead of index === signalIndexName
  • data view titles allow for duplicate indices, so we need to allow for duplicates to display accurate data view titles. For example: auditbeat-*,auditbeat-*,auditbeat-*,auditbeat-* and auditbeat-*,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 fields
    • there is another spot where i know you'll be like, why check for duplicates here? its in case something wonky is in the url state
  • the data view gets updated when the Advanced Settings default index is updated securitySolution:defaultIndex. A page refresh is required for updates to take place
  • the siem signals index is appended to the end of the security-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 the security-solution data view when the signalIndexName is updated
  • when the data view gets deleted and you navigate back to the security solution, a page refresh will be forced to regenerate the data view
  • to check if an index pattern is valid, we are now using esClient.fieldCaps instead of esClient.search or esClient.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 using esClient.fieldCaps will tell us if the index exists even without data

UI 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:
sourcerer_demo

Runtime Fields in Security Solution:
rtf_demo

Checklist

const { id, ...rest } = defaultDataView;
if (id === null) {
// if id is null, rest is error
addError(rest, {
Copy link
Contributor

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

Copy link
Contributor

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`],
Copy link
Contributor

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

@@ -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;
Copy link
Contributor

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

Copy link
Contributor Author

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}>
Copy link
Contributor

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.

x-pack/plugins/security_solution/public/plugin.tsx Outdated Show resolved Hide resolved
@stephmilovic
Copy link
Contributor Author

@elasticmachine merge upstream

@stephmilovic
Copy link
Contributor Author

Closing in favor of: #114806

@kibanamachine
Copy link
Contributor

kibanamachine commented Oct 13, 2021

💔 Build Failed

Failed CI Steps


Test Failures

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 case

Link to Jenkins

Stack Trace

Failed Tests Reporter:
  - Test has not failed recently on tracked branches

AssertionError: Timed out retrying after 60000ms: Expected to find element: `[data-test-subj="caseTitle"] [data-test-subj="input"]`, but never found it.
    at Object.fillCasesMandatoryfields (http://localhost:61171/__cypress/tests?p=cypress/integration/cases/privileges.spec.ts:33782:8)
    at Context.eval (http://localhost:61171/__cypress/tests?p=cypress/integration/cases/privileges.spec.ts:32794:31)

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 case

Link to Jenkins

Stack Trace

Failed Tests Reporter:
  - Test has not failed recently on tracked branches

AssertionError: Timed out retrying after 60000ms: Expected to find element: `[data-test-subj="createNewCaseBtn"]`, but never found it.
    at Object.goToCreateNewCase (http://localhost:61171/__cypress/tests?p=cypress/integration/cases/privileges.spec.ts:33583:8)
    at Context.eval (http://localhost:61171/__cypress/tests?p=cypress/integration/cases/privileges.spec.ts:32793:25)

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 case

Link to Jenkins

Stack Trace

Failed Tests Reporter:
  - Test has failed 1 times on tracked branches: https://dryrun

AssertionError: Timed out retrying after 60000ms: Expected to find element: `[data-test-subj="createNewCaseBtn"]`, but never found it.
    at Object.goToCreateNewCase (http://localhost:61171/__cypress/tests?p=cypress/integration/cases/privileges.spec.ts:33583:8)
    at Context.eval (http://localhost:61171/__cypress/tests?p=cypress/integration/cases/privileges.spec.ts:32793:25)

and 1 more failures, only showing the first 3.

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
securitySolution 1307 1319 +12
timelines 847 863 +16
total +28

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
observability 363.1KB 363.2KB +19.0B
securitySolution 4.6MB 4.6MB +7.9KB
timelines 240.0KB 240.2KB +194.0B
total +8.1KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
securitySolution 104.1KB 104.9KB +787.0B
timelines 156.6KB 156.8KB +166.0B
total +953.0B
Unknown metric groups

API count

id before after diff
securitySolution 1361 1373 +12
timelines 968 984 +16
total +28

References to deprecated APIs

id before after diff
securitySolution 1001 995 -6
timelines 84 91 +7
total +1

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Deprecated - use backport:version if exact versions are needed release_note:enhancement Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Threat Hunting Security Solution Threat Hunting Team v8.0.0 WIP Work in progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants