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

[RAC] - Update field names #107857

Merged
merged 19 commits into from
Aug 11, 2021
Merged

Conversation

yctercero
Copy link
Contributor

@yctercero yctercero commented Aug 8, 2021

Summary

Trying to align on field naming. In the code there seems to be the following that are all referencing the context in which a rule instance was created (rules created in stack have consumer of alerts):

  • rule.consumers
  • kibana.alert.consumer
  • kibana.alert.consumers
  • kibana.alert.rule.consumers
  • kibana.alert.owner

In the code there are also the following all referencing a rule's alert type (ex: apm.error_rate):

  • rule.id
  • kibana.alert.rule.rule_type_id

It's my understanding that these are all meant to refer to the same thing - the single feature which created the rule instance. So if a rule was created in security solution, the consumer is siem, if created in apm it's apm. Observability and the rule registry were using kibana.alert.owner though it'd been on the list to update to kibana.alert.consumer and security solution was using kibana.alert.owners. The other ones were there as fields but not being used.

I think there is some confusion as to what consumer is meant to denote. It should denote the same thing it does for rules rbac. If there's other context we want to save on an alert, that should be considered a different field, the consumer field was meant to be specific to role based access logic shared with alerting framework.

Fields used moving forward

kibana.alert.rule.consumer will refer to the context in which a rule instance is created. Rules created in:

  • stack --> alerts
  • security solution --> siem
  • apm --> apm

kibana.alert.rule.producer will refer to the plugin that registered a rule type. Rules registered in:

  • stack --> alerts
  • security solution --> siem
  • apm --> apm

So an apm.error_rate rule created in stack will have:

  • consumer: alerts and producer: apm
    An apm.error_rate rule created in apm will have:
  • consumer: apm and producer: apm

kibana.alert.rule.rule_type_id will refer to a rule's rule type id. Examples:

  • apm.error_rate
  • siem.signals
  • siem.threshold

Also renamed the following because rule.* fields are meant to be ecs fields pulled from the source/event document, not refer to our rule fields.
rule.name --> kibana.alert.rule.name will refer to the rule's name.

rule.category --> kibana.alert.rule.category will refer to the rule's category.

rule.id --> kibana.alert.rule.uuid will refer to the rule's uuid.

To test

Add the following to your kibana.dev.yml:

xpack.securitySolution.enableExperimental: ['tGridEnabled']

Create a custom rule with query *:*.

Run yarn test:generate within x-pack/plugins/security_solution

Observe the magic (alerts should show up in table).

Screen Shot 2021-08-10 at 10 35 32 PM

@yctercero yctercero self-assigned this Aug 9, 2021
@yctercero yctercero added Feature:RAC label obsolete Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Detections and Resp Security Detection Response Team Team:Threat Hunting Security Solution Threat Hunting Team v7.15.0 v8.0.0 labels Aug 9, 2021
@yctercero yctercero changed the title Update ss field names [RAC] - Update field names Aug 9, 2021
@yctercero yctercero marked this pull request as ready for review August 9, 2021 13:35
@yctercero yctercero requested review from a team as code owners August 9, 2021 13:35
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detections-response (Team:Detections and Resp)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-solution (Team: SecuritySolution)

@botelastic botelastic bot added the Team:APM All issues that need APM UI Team support label Aug 9, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/apm-ui (Team:apm)

@yctercero yctercero added the release_note:skip Skip the PR/issue when compiling release notes label Aug 9, 2021
Copy link
Contributor

@ecezalp ecezalp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - thanks for consolidating the fields!

Copy link
Contributor

@michaelolo24 michaelolo24 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for doing this! Tested locally with @machadoum and looks great, just one minor comment 😄

@yctercero yctercero requested a review from a team as a code owner August 9, 2021 16:38
Copy link
Contributor

@gmmorris gmmorris left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the Alerting code- looks like the only change is the input and output of a couple of unit tests and looks like it was made to make maintenance easier so all I can say is thanks Yara :)

LGTM

@michaelolo24
Copy link
Contributor

Just a comment to uncomment these when it's all sorted: #108034

@@ -17,25 +17,18 @@ const CONSUMERS = `${KIBANA_NAMESPACE}.consumers` as const;
const ECS_VERSION = 'ecs.version' as const;
const EVENT_ACTION = 'event.action' as const;
const EVENT_KIND = 'event.kind' as const;
const RULE_CATEGORY = 'rule.category' as const;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rule.* should only refer to source/event document fields, not our kibana rules.

[Fields.ALERT_PRODUCER]: { type: 'keyword' },
[Fields.ALERT_RULE_TYPE_ID]: { type: 'keyword', required: true },
[Fields.ALERT_RULE_CONSUMER]: { type: 'keyword', required: true },
[Fields.ALERT_RULE_PRODUCER]: { type: 'keyword' },
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Producer can be derived from the rule type id (apm.error_count) --> apm , so while convenient, we don't need to require it as long as we have the consumer and rule type id, we have enough for rbac.

@yctercero yctercero removed the request for review from a team August 10, 2021 21:54
@yctercero yctercero enabled auto-merge (squash) August 11, 2021 05:39
Copy link
Member

@dgieselaar dgieselaar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

APM changes LGTM!

@yctercero yctercero added the auto-backport Deprecated - use backport:version if exact versions are needed label Aug 11, 2021
@yctercero
Copy link
Contributor Author

@elasticmachine merge upstream

@yctercero
Copy link
Contributor Author

Just a comment to uncomment these when it's all sorted: #108034

@michaelolo24 Note that after most recent CI failure, took the opportunity to make these changes here so once this goes in, should be golden 👍🏽

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Async chunks

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

id before after diff
apm 4.3MB 4.3MB -662.0B
observability 481.8KB 480.8KB -1015.0B
securitySolution 6.5MB 6.5MB -4.0B
total -1.6KB

Page load bundle

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

id before after diff
apm 44.9KB 44.7KB -225.0B
infra 150.1KB 149.9KB -225.0B
uptime 35.7KB 35.4KB -225.0B
total -675.0B

History

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

cc @yctercero

@yctercero yctercero merged commit cec5d3f into elastic:master Aug 11, 2021
kibanamachine pushed a commit to kibanamachine/kibana that referenced this pull request Aug 11, 2021
### Summary
### Fields used moving forward
`kibana.alert.rule.consumer` will refer to the context in which a rule instance is created. Rules created in:
- stack --> `alerts`
- security solution --> `siem`
- apm --> `apm`

`kibana.alert.rule.producer` will refer to the plugin that registered a rule type. Rules registered in:
- stack --> `alerts`
- security solution --> `siem`
- apm --> `apm`

So an `apm.error_rate` rule created in stack will have:
- consumer: `alerts` and producer: `apm`
 An `apm.error_rate` rule created in apm will have:
- consumer: `apm` and producer: `apm`

`kibana.alert.rule.rule_type_id` will refer to a rule's rule type id. Examples:
- `apm.error_rate`
- `siem.signals`
- `siem.threshold`

Also renamed the following because `rule.*` fields are meant to be ecs fields pulled from the source/event document, not refer to our rule fields.
`rule.name` --> `kibana.alert.rule.name` will refer to the rule's name.

`rule.category` --> `kibana.alert.rule.category` will refer to the rule's category.

`rule.id` --> `kibana.alert.rule.uuid` will refer to the rule's uuid.
@kibanamachine
Copy link
Contributor

💚 Backport successful

Status Branch Result
7.x

This backport PR will be merged automatically after passing CI.

kibanamachine added a commit that referenced this pull request Aug 11, 2021
### Summary
### Fields used moving forward
`kibana.alert.rule.consumer` will refer to the context in which a rule instance is created. Rules created in:
- stack --> `alerts`
- security solution --> `siem`
- apm --> `apm`

`kibana.alert.rule.producer` will refer to the plugin that registered a rule type. Rules registered in:
- stack --> `alerts`
- security solution --> `siem`
- apm --> `apm`

So an `apm.error_rate` rule created in stack will have:
- consumer: `alerts` and producer: `apm`
 An `apm.error_rate` rule created in apm will have:
- consumer: `apm` and producer: `apm`

`kibana.alert.rule.rule_type_id` will refer to a rule's rule type id. Examples:
- `apm.error_rate`
- `siem.signals`
- `siem.threshold`

Also renamed the following because `rule.*` fields are meant to be ecs fields pulled from the source/event document, not refer to our rule fields.
`rule.name` --> `kibana.alert.rule.name` will refer to the rule's name.

`rule.category` --> `kibana.alert.rule.category` will refer to the rule's category.

`rule.id` --> `kibana.alert.rule.uuid` will refer to the rule's uuid.

Co-authored-by: Yara Tercero <yctercero@users.noreply.github.com>
@yctercero yctercero deleted the update_ss_field_names branch August 11, 2021 16:26
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 Feature:RAC label obsolete release_note:skip Skip the PR/issue when compiling release notes Team:APM All issues that need APM UI Team support Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Team:Threat Hunting Security Solution Threat Hunting Team v7.15.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants