[Security Solution] [Attack discovery] Attack Discovery RBAC / Display an upgrade CTA for the serverless essentials product tier

[andrew-goldstein]

[Security Solution] [Attack discovery] Attack Discovery RBAC / Display an upgrade CTA for the serverless essentials product tier

Summary

This PR adds Role Based Access Control (RBAC) to Attack discovery.

Security users may enable or disable the new Attack Discovery RBAC feature shown in the figure below:

Above: The new Attack discovery RBAC feature

It is possible to for example, configure a custom role that enables Attack discovery, but disables the assistant, as illustrated by the table below:

Role	License	Navigation visible	Show upsell	Upsell has actions	View in assistant enabled
has_attack_discovery_all_assistant_none	Basic	✅	✅	✅	❌
has_attack_discovery_all_assistant_none	Trial	✅	❌	❌	❌
has_attack_discovery_all_assistant_none	Platinum	✅	✅	✅	❌
has_attack_discovery_all_assistant_none	Enterprise	✅	❌	❌	❌

Above: An example role that enables Attack discovery, but disables the assistant

See the Desk Testing section of this PR for details.

This PR also fixes an issue where Attack discovery does not display an upgrade call to action (CTA) for the serverless essentials product tier, per the before and after screenshots below:

Before

Above: Before the fix, an upgrade CTA is NOT displayed for the serverless essentials product tier

After

Above: After the fix, an upgrade CTA is displayed for the serverless essentials product tier

The fix above is implemented by adopting the upselling framework.

New Feature ID

This PR adds a new Feature ID for attack discovery:

export const ATTACK_DISCOVERY_FEATURE_ID = 'securitySolutionAttackDiscovery' as const;

in x-pack/packages/security-solution/features/src/constants.ts

Upselling framework usage

This PR updates the Attack discovery page to use the upselling framework via the following summarized steps:

1. Removed the branching logic from x-pack/plugins/security_solution/public/attack_discovery/pages/upgrade/index.tsx, and moved the component to an upselling section component in x-pack/packages/security-solution/upselling/sections/attack_discovery/index.tsx, where the component was renamed to AttackDiscoveryUpsellingSection.

This section component handles (just) the styling of the upselling message and actions (by itself, without the page wrapper), and receives the following props:

interface Props {
  actions?: React.ReactNode;
  availabilityMessage: string;
  upgradeMessage: string;
}

The self managed and serverless-specific actions and i18n messages are passed down via the components described in the later steps below.

2. Removed all previous references to the Upgrade component (and references to useProductTypes) from the Attack discovery page in x-pack/plugins/security_solution/public/attack_discovery/pages/index.tsx, because the framework manages the upgrade case instead of the page itself.

3. Created an upselling page component AttackDiscoveryUpsellingPage in x-pack/packages/security-solution/upselling/pages/attack_discovery/index.tsx.

This component handles (just) the styling of the page that wraps the Attack discovery section. It passes the same props to the previously described AttackDiscoveryUpsellingSection component.

4. Created a self-managed-specific AttackDiscoveryUpsellingPageESS component in x-pack/plugins/security_solution_ess/public/upselling/pages/attack_discovery/index.tsx

This component passes self-managed-specific upgrade action buttons / links and i18n strings to the previously described AttackDiscoveryUpsellingPage

5. Also for self managed, added a new AttackDiscoveryUpsellingPageLazy component to the existing file: x-pack/plugins/security_solution_ess/public/upselling/lazy_upselling.tsx

This component lazy loads the previously described AttackDiscoveryUpsellingPageESS component.

6. Added registration for the previously described AttackDiscoveryUpsellingPageLazy component to the existing UpsellingPages section in x-pack/plugins/security_solution_ess/public/upselling/register_upsellings.tsx with a minimumLicenseRequired of enterprise:

minimumLicenseRequired: 'enterprise',

7. Created a serverless-specific AttackDiscoveryUpsellingPageServerless component in x-pack/plugins/security_solution_serverless/public/upselling/pages/attack_discovery/index.tsx

This component passes serverless-specific i18n messages to the platform agnostic AttackDiscoveryUpsellingPage component.

8. Also for serverless, added a new AttackDiscoveryUpsellingPageLazy component to the existing file: x-pack/plugins/security_solution_serverless/public/upselling/lazy_upselling.tsx

9. Added registration for the previously described AttackDiscoveryUpsellingPageLazy component to the existing upsellingPages section in x-pack/plugins/security_solution_serverless/public/upselling/upsellings.tsx with the assistant PLI:

pli: ProductFeatureKey.assistant,

10. Added the ${ASSISTANT_FEATURE_ID}.ai-assistant capability as an OR condition (via nested array, per the framework) to the Attack discovery link in x-pack/plugins/security_solution/public/attack_discovery/links.ts. This addition enables the security route wrapper to check for upselling pages in serverless:

capabilities: [[`${SERVER_APP_ID}.show`, `${ASSISTANT_FEATURE_ID}.ai-assistant`]],

11. Added licenseType: 'enterprise' to the Attack discovery link in x-pack/plugins/security_solution/public/attack_discovery/links.ts to require an enterprise license for self managed

Upgrade CTA gallery

The screenshots in this section document the CTA (or Welcome message when the feature is licensed) displayed for various license levels after the fix:

Users with the None privilege

If users with the None privilege manually enter an Attack discovery URL, e.g. http://localhost:5601/app/security/attack_discovery, the framework will display the following error prompt:

Self managed BASIC

Self managed PLATINUM

Self managed TRIAL

Self managed ENTERPRISE

Serverless ESSENTIALS

Serverless COMPLETE

Desk Testing

Severless: Desk testing (just) the upgrade CTA

Reproduction steps:

1. Comment-out any preconfigured connectors in config/kibana.dev.yml

2. Edit the configuration of config/serverless.security.yml to enable the essentials product tier:

xpack.securitySolutionServerless.productTypes:
  [
    { product_line: 'security', product_tier: 'essentials' }
  ]

3. Start Elasticsearch

yarn es serverless --projectType security

4. Start a development instance of Kibana

yarn start --serverless=security --no-base-path

5. Navigate to Security > Attack discovery

Expected result

• An upgrade CTA is displayed, as illustrated by the after screenshot below:

• The video tour is NOT displayed for serverless, as noted in the original PR

Actual result

• An upgrade CTA is NOT displayed, as illustrated by the before screenshot below:

Desk testing Self Managed

To desk test self manged, we will:

1. Create (three) roles for testing
2. Create (three) users assigned to the roles
3. Test each role at Basic, Trial, Platinum, and Enterprise levels to verify:

• Attack discovery link visibility in the Security solution navigation
• Visibility of the upsell empty prompt for license levels where Attack discovery is unavailable
• The upsell empty prompt includes the Subscription plans and Manage license actions
• When Attack discoveries are generated, the View in Ai Assistant button and popover menu action are enabled / disabled, based on availability of the AI Assistant feature

Creating (three) roles for testing

In this section, we will start a new (development) self managed deployment, and create the following three roles via Kibana Dev Tools:

• has_attack_discovery_all_assistant_all
• has_attack_discovery_all_assistant_none
• has_attack_discovery_none_assistant_all

To start the deployment and create the roles:

1. Add a pre-configured GenAI connector to config/kibana.dev.yml

2. Start a new (development) instance of Elasticsearch:

yarn es snapshot -E path.data=/Users/$USERNAME/data-2024-07-31a

3. Start a local (development) instance of Kibana:

yarn start --no-base-path

4. Login to Kibana as the elastic user

5. Generate some alerts

6. Navigate to Dev Tools

7. Execute the following three API calls to create the roles:

PUT /_security/role/has_attack_discovery_all_assistant_all

PUT /_security/role/has_attack_discovery_all_assistant_all
{
  "cluster": [
    "all"
  ],
  "indices": [
    {
      "names": [
        "*"
      ],
      "privileges": [
        "all"
      ],
      "field_security": {
        "grant": [
          "*"
        ],
        "except": []
      },
      "allow_restricted_indices": false
    }
  ],
  "applications": [
    {
      "application": "kibana-.kibana",
      "privileges": [
        "feature_securitySolutionAssistant.minimal_all",
        "feature_securitySolutionAttackDiscovery.minimal_all",
        "feature_siem.all",
        "feature_securitySolutionCases.all",
        "feature_actions.all"
      ],
      "resources": [
        "*"
      ]
    }
  ],
  "run_as": [],
  "metadata": {},
  "transient_metadata": {
    "enabled": true
  }
}

PUT /_security/role/has_attack_discovery_all_assistant_none

PUT /_security/role/has_attack_discovery_all_assistant_none
{
  "cluster": [
    "all"
  ],
  "indices": [
    {
      "names": [
        "*"
      ],
      "privileges": [
        "all"
      ],
      "field_security": {
        "grant": [
          "*"
        ],
        "except": []
      },
      "allow_restricted_indices": false
    }
  ],
  "applications": [
    {
      "application": "kibana-.kibana",
      "privileges": [
        "feature_securitySolutionAttackDiscovery.minimal_all",
        "feature_siem.all",
        "feature_securitySolutionCases.all",
        "feature_actions.all"
      ],
      "resources": [
        "*"
      ]
    }
  ],
  "run_as": [],
  "metadata": {},
  "transient_metadata": {
    "enabled": true
  }
}

PUT /_security/role/has_attack_discovery_none_assistant_all

PUT /_security/role/has_attack_discovery_none_assistant_all
{
  "cluster": [
    "all"
  ],
  "indices": [
    {
      "names": [
        "*"
      ],
      "privileges": [
        "all"
      ],
      "field_security": {
        "grant": [
          "*"
        ],
        "except": []
      },
      "allow_restricted_indices": false
    }
  ],
  "applications": [
    {
      "application": "kibana-.kibana",
      "privileges": [
        "feature_securitySolutionAssistant.minimal_all",
        "feature_siem.all",
        "feature_securitySolutionCases.all",
        "feature_actions.all"
      ],
      "resources": [
        "*"
      ]
    }
  ],
  "run_as": [],
  "metadata": {},
  "transient_metadata": {
    "enabled": true
  }
}

Creating (three) users assigned to the roles

In this section, we will create the following three users via Kibana Dev Tools using the API calls below (expand for details):

• attack_discovery_all_assistant_all
• attack_discovery_all_assistant_none
• attack_discovery_none_assistant_all

1. Navigate to Dev Tools

2. Execute the following three API calls to create the users:

POST /_security/user/attack_discovery_all_assistant_all

POST /_security/user/attack_discovery_all_assistant_all
{
    "username": "attack_discovery_all_assistant_all",
    "password": "changeme",
    "roles": [
      "has_attack_discovery_all_assistant_all"
    ],
    "full_name": "Attack Discovery All Assistant All",
    "email": "user@example.com",
    "metadata": {},
    "enabled": true
}

POST /_security/user/attack_discovery_all_assistant_none

POST /_security/user/attack_discovery_all_assistant_none
{
    "username": "attack_discovery_all_assistant_none",
    "password": "changeme",
    "roles": [
      "has_attack_discovery_all_assistant_none"
    ],
    "full_name": "Attack Discovery All Assistant None",
    "email": "user@example.com",
    "metadata": {},
    "enabled": true
}

POST /_security/user/attack_discovery_none_assistant_all

POST /_security/user/attack_discovery_none_assistant_all
{
    "username": "attack_discovery_none_assistant_all",
    "password": "changeme",
    "roles": [
      "has_attack_discovery_none_assistant_all"
    ],
    "full_name": "Attack Discovery None Assistant All",
    "email": "user@example.com",
    "metadata": {},
    "enabled": true
}

Testing each role at Basic, Trial, Platinum, and Enterprise levels

In this section, we will test each of the self managed Basic, Trial, Platinum, and Enterprise license levels with the three roles we created for testing.

Testing the has_attack_discovery_all_assistant_all role

1. Login as the attack_discovery_all_assistant_all user

2. Navigate to the Security solution

3. For each of the Basic, Trial, Platinum, and Enterprise levels, verify your observations match the expected behavior in the table below:

Role	License	Navigation visible	Show upsell	Upsell has actions	View in assistant enabled
has_attack_discovery_all_assistant_all	Basic	✅	✅	✅	❌
has_attack_discovery_all_assistant_all	Trial	✅	❌	❌	✅
has_attack_discovery_all_assistant_all	Platinum	✅	✅	✅	❌
has_attack_discovery_all_assistant_all	Enterprise	✅	❌	❌	✅

Testing the has_attack_discovery_all_assistant_none role

1. Login as the attack_discovery_all_assistant_none user

2. Navigate to the Security solution

3. For each of the Basic, Trial, Platinum, and Enterprise levels, verify your observations match the expected behavior in the table below:

Role	License	Navigation visible	Show upsell	Upsell has actions	View in assistant enabled
has_attack_discovery_all_assistant_none	Basic	✅	✅	✅	❌
has_attack_discovery_all_assistant_none	Trial	✅	❌	❌	❌
has_attack_discovery_all_assistant_none	Platinum	✅	✅	✅	❌
has_attack_discovery_all_assistant_none	Enterprise	✅	❌	❌	❌

Testing the has_attack_discovery_none_assistant_all role

1. Login as the attack_discovery_none_assistant_all user

2. Navigate to the Security solution

3. For each of the Basic, Trial, Platinum, and Enterprise levels, verify your observations match the expected behavior in the table below:

Role	License	Navigation visible	Show upsell	Upsell has actions	View in assistant enabled
has_attack_discovery_none_assistant_all	Basic	✅	✅	✅	❌
has_attack_discovery_none_assistant_all	Trial	❌	❌	❌	❌
has_attack_discovery_none_assistant_all	Platinum	✅	✅	✅	❌
has_attack_discovery_none_assistant_all	Enterprise	❌	❌	❌	❌

---

Serverless Testing

To desk test serverless, we will test the essentials and complete product tiers to verify:

• Attack discovery link visibility in the Security project navigation
• Visibility of the upsell empty prompt for license levels where Attack discovery is unavailable
• The upsell empty prompt does NOT include the Subscription plans and Manage license actions
• When Attack discoveries are generated, the View in Ai Assistant button and popover menu action are enabled

Essentials tier testing

1. Add a pre-configured GenAI connector to config/kibana.dev.yml

2. Edit the configuration of config/serverless.security.yml to enable the essentials product tier:

xpack.securitySolutionServerless.productTypes:
  [
    { product_line: 'security', product_tier: 'essentials' },
    { product_line: 'endpoint', product_tier: 'essentials' },
  ]

2. Start a new (development) instance of Elasticsearch:

yarn es serverless --clean --projectType security

3. Start a local (development) instance of Kibana:

yarn start --serverless=security --no-base-path

4. select the admin role

5. Generate some alerts

6. Verify your observations match the expected behavior in the table below:

Role	Tier	Navigation visible	Show upsell	Upsell has actions	View in assistant enabled
viewer	essentials	✅	✅	❌	❌
editor	essentials	✅	✅	❌	❌
t1_analyst	essentials	✅	✅	❌	❌
t2_analyst	essentials	✅	✅	❌	❌
t3_analyst	essentials	✅	✅	❌	❌
threat_intelligence_analyst	essentials	✅	✅	❌	❌
rule_author	essentials	✅	✅	❌	❌
soc_manager	essentials	✅	✅	❌	❌
detections_admin	essentials	✅	✅	❌	❌
platform_engineer	essentials	✅	✅	❌	❌
endpoint_operations_analyst	essentials	✅	✅	❌	❌
endpoint_policy_manager	essentials	✅	✅	❌	❌
admin	essentials	✅	✅	❌	❌
system_indices_superuser	essentials	✅	✅	❌	❌

Complete tier testing

1. Stop the running Kibana server (from the previous Essentials tier testing)

2. Edit the configuration of config/serverless.security.yml to enable the complete product tier:

xpack.securitySolutionServerless.productTypes:
  [
    { product_line: 'security', product_tier: 'complete' },
    { product_line: 'endpoint', product_tier: 'complete' },
  ]

3. Restart a local (development) instance of Kibana:

yarn start --serverless=security --no-base-path

4. Verify your observations match the expected behavior in the table below:

Role	Tier	Navigation visible	Show upsell	Upsell has actions	View in assistant enabled
viewer	complete	✅	❌	❌	✅
editor	complete	✅	❌	❌	✅
t1_analyst	complete	✅	❌	❌	✅
t2_analyst	complete	✅	❌	❌	✅
t3_analyst	complete	✅	❌	❌	✅
threat_intelligence_analyst	complete	✅	❌	❌	✅
rule_author	complete	✅	❌	❌	✅
soc_manager	complete	✅	❌	❌	✅
detections_admin	complete	✅	❌	❌	✅
platform_engineer	complete	✅	❌	❌	✅
endpoint_operations_analyst	complete	✅	❌	❌	✅
endpoint_policy_manager	complete	✅	❌	❌	✅
admin	complete	✅	❌	❌	✅
system_indices_superuser	complete	✅	❌	❌	✅

[elasticmachine]

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

[semd]

Hi Andrew, we already have a framework in place for Upselling/CLA pages.

This PR is reimplementing the same thing only for Attack Discovery, and it is adding serverless-specific logic in the security_solution plugin, which is breaking the convention of keeping this plugin "offering agnostic". It is also not using the PLI config for ProductFeatureKey.assistant, which means that if we change the centralized pli_config this CLA page will still appear.

The Onboarding page, to which this PR is adding a dependency from Attack discovery, is going to be refactored soon, and all code related to productTypes (serverless-specific) will be moved to the security_solution_serverless plugin.

If this is an urgent bug fix I am fine merging it as a temporary patch, but it would make the onboarding page refactoring much harder. So I strongly suggest changing the approach to use the existing upselling service.

Suggestion

We only need to register the CLA components here for serverless, and here for stateful, using pli: ProductFeatureKey.assistant. And change the capabilities required for the Attack Discover page in the config:

kibana/x-pack/plugins/security_solution/public/attack_discovery/links.ts

Line 15 in 7089f35

capabilities: [`${SERVER_APP_ID}.show`],

by:
capabilities: [[`${SERVER_APP_ID}.show`, ${ASSISTANT_FEATURE_ID}.ai-assistant`]], // both capabilities are required

And that's it, all the branching logic will already be taken care of by the framework, according to the PLI config. It will also integrate RBAC for free.
Let me know if I can help.

As a reference this is the implementation for the Threat Intel page paywall for serverless.

[semd]

This hook was created as a temporary workaround and is going to be removed.

[andrew-goldstein]

This hook was created as a temporary workaround and is going to be removed.

Thanks @semd for the feedback suggesting to instead use the Upselling/CLA framework!

I took the following actions to implement the feedback:

• updated the PR to use the Upselling/CLA framework in this commit
• added a new section to the PR description, titled Upselling framework usage with the details below
• rested and updated all screenshots in the PR description

The following summary describes the changes made in this PR to adopt the framework:

1. Removed the branching logic from x-pack/plugins/security_solution/public/attack_discovery/pages/upgrade/index.tsx, and moved the component to an upselling section component in x-pack/packages/security-solution/upselling/sections/attack_discovery/index.tsx, where the component was renamed to AttackDiscoveryUpsellingSection.

This section component handles (just) the styling of the upselling message and actions (by itself, without the page wrapper), and receives the following props:

interface Props {
  actions?: React.ReactNode;
  availabilityMessage: string;
  upgradeMessage: string;
}

The self managed and serverless-specific actions and i18n messages are passed down via the components described in the later steps below.

2. Removed all previous references to the Upgrade component (and references to useProductTypes) from the Attack discovery page in x-pack/plugins/security_solution/public/attack_discovery/pages/index.tsx, because the framework manages the upgrade case instead of the page itself.

3. Created an upselling page component AttackDiscoveryUpsellingPage in x-pack/packages/security-solution/upselling/pages/attack_discovery/index.tsx.

This component handles (just) the styling of the page that wraps the Attack discovery section. It passes the same props to the previously described AttackDiscoveryUpsellingSection component.

4. Created a self-managed-specific AttackDiscoveryUpsellingPageESS component in x-pack/plugins/security_solution_ess/public/upselling/pages/attack_discovery/index.tsx

This component passes self-managed-specific upgrade action buttons / links and i18n strings to the previously described AttackDiscoveryUpsellingPage

5. Also for self managed, added a new AttackDiscoveryUpsellingPageLazy component to the existing file: x-pack/plugins/security_solution_ess/public/upselling/lazy_upselling.tsx

This component lazy loads the previously described AttackDiscoveryUpsellingPageESS component.

6. Added registration for the previously described AttackDiscoveryUpsellingPageLazy component to the existing UpsellingPages section in x-pack/plugins/security_solution_ess/public/upselling/register_upsellings.tsx with a minimumLicenseRequired of enterprise:

minimumLicenseRequired: 'enterprise',

7. Created a serverless-specific AttackDiscoveryUpsellingPageServerless component in x-pack/plugins/security_solution_serverless/public/upselling/pages/attack_discovery/index.tsx

This component passes serverless-specific i18n messages to the platform agnostic AttackDiscoveryUpsellingPage component.

8. Also for serverless, added a new AttackDiscoveryUpsellingPageLazy component to the existing file: x-pack/plugins/security_solution_serverless/public/upselling/lazy_upselling.tsx

9. Added registration for the previously described AttackDiscoveryUpsellingPageLazy component to the existing upsellingPages section in x-pack/plugins/security_solution_serverless/public/upselling/upsellings.tsx with the assistant PLI:

pli: ProductFeatureKey.assistant,

10. Added the ${ASSISTANT_FEATURE_ID}.ai-assistant capability as an OR condition (via nested array, per the framework) to the Attack discovery link in x-pack/plugins/security_solution/public/attack_discovery/links.ts. This addition enables the security route wrapper to check for upselling pages in serverless:

capabilities: [[`${SERVER_APP_ID}.show`, `${ASSISTANT_FEATURE_ID}.ai-assistant`]],

11. Added licenseType: 'enterprise' to the Attack discovery link in x-pack/plugins/security_solution/public/attack_discovery/links.ts to require an enterprise license for self managed

[andrew-goldstein]

Files by Code Owner

elastic/kibana-core

• x-pack/plugins/security_solution_ess/kibana.jsonc
• x-pack/plugins/security_solution_serverless/kibana.jsonc

elastic/security-threat-hunting-explore

• x-pack/packages/security-solution/upselling/pages/attack_discovery/index.test.tsx
• x-pack/packages/security-solution/upselling/pages/attack_discovery/index.tsx
• x-pack/packages/security-solution/upselling/pages/attack_discovery/page_title/index.test.tsx
• x-pack/packages/security-solution/upselling/pages/attack_discovery/page_title/index.tsx
• x-pack/packages/security-solution/upselling/pages/attack_discovery/page_title/translations.ts
• x-pack/packages/security-solution/upselling/sections/attack_discovery/index.test.tsx
• x-pack/packages/security-solution/upselling/sections/attack_discovery/index.tsx
• x-pack/packages/security-solution/upselling/sections/attack_discovery/translations.ts
• x-pack/packages/security-solution/upselling/tsconfig.json

[paul-tavares]

LGTM (on behalf of elastic/security-defend-workflows )

[elena-shostak]

Left a few comments.
Also, I've noticed that icons appear slightly offset on mobile

[elena-shostak]

Security changes LGTM!

[andrew-goldstein]

Left a few comments. Also, I've noticed that icons appear slightly offset on mobile

Thanks @elena-shostak! I implemented your feedback in 22a9ed8 , as illustrated by the animated gif below:

[YulNaumenko]

LGTM!

[maximpn]

D&R LGTM

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 6e6300f

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	5654	5652	-2
securitySolutionEss	108	118	+10
securitySolutionServerless	135	143	+8
total			+16

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
@kbn/security-solution-features	14	15	+1

Async chunks

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

id	before	after	diff
securitySolution	20.7MB	20.7MB	-2.6KB
securitySolutionEss	39.5KB	58.7KB	+19.3KB
securitySolutionServerless	114.8KB	119.2KB	+4.3KB
total			+21.0KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
@kbn/security-solution-features	6	7	+1

Page load bundle

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

id	before	after	diff
securitySolution	86.1KB	86.2KB	+73.0B
securitySolutionEss	16.1KB	16.3KB	+208.0B
securitySolutionServerless	21.0KB	21.4KB	+346.0B
total			+627.0B

Unknown metric groups

API count

id	before	after	diff
@kbn/security-solution-features	14	15	+1

async chunk count

id	before	after	diff
securitySolutionEss	3	4	+1
securitySolutionServerless	13	14	+1
total			+2

History

• 💛 Build #227180 was flaky eb770b8fe5351d2b5925c6abb2dd684684012d7a
• 💔 Build #227166 failed b2361c762b3e6a614f2362961d02dbff9fdcd063
• 💔 Build #226166 failed 22a9ed859867f3c0ff0d796534007d664a781338
• 💚 Build #224162 succeeded e912e39dbeb6ce5cbd11ab1bd49b3f3c7a8c1106
• 💚 Build #223912 succeeded 072a00b12d04bc572786dada21bfaae15f7c6c52
• 💔 Build #223365 failed 4bfd2e146b6a0338633d1ffa508e7b3db2418d5c

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

cc @andrew-goldstein