[Security Solution][PoC] AI 4 SOC navigation approach 2 #212652

semd · 2025-02-27T13:14:24Z

Summary

This approach implements the RBAC by disabling (not registering) entire Kibana features.

Approach 1 is: #212128

Screenshots

Security + AI

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

Left nav

Custom roles creation

Only AI

xpack.securitySolutionServerless.productTypes:
  [
    { product_line: 'ai_soc', product_tier: 'search_ai_lake' },
  ]

Left nav

Custom role creation

Only security

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

Left nav

...

Custom role creation

elasticmachine · 2025-02-27T13:14:40Z

🤖 Jobs for this PR can be triggered through checkboxes. 🚧

ℹ️ To trigger the CI, please tick the checkbox below 👇

Click to trigger kibana-pull-request for this PR!
Click to trigger kibana-deploy-project-from-pr for this PR!
Click to trigger kibana-deploy-cloud-from-pr for this PR!

semd · 2025-02-28T12:24:25Z

x-pack/platform/plugins/shared/features/server/feature_registry.ts

@@ -108,6 +108,7 @@ export class FeatureRegistry {
    for (const [featureId, featureOverride] of Object.entries(overrides)) {
      const feature = this.kibanaFeatures[featureId];
      if (!feature) {
+        continue;


This needs to be discussed with @elastic/kibana-security

I have a few questions to better understand what you’re trying to achieve:

What is the process for changing the product tier/line?

Is it something a user can do themselves?

Is the current tier stored somewhere in ES, or is it a config value?

Does the change require a Kibana restart?

In which offerings is it possible to dynamically update tiers/lines (ECH, ECS, on-prem)?

I vaguely remember that dynamic configuration was only possible in Elastic Cloud (or even only in Serverless?), where the configuration flag for the current tier lived in the Kibana config and was managed by infra (controller?). Is that still the case? If so, is there any reason the code that changes the tier config in the Kibana config couldn’t also alter overrides in the config?

To the best of my knowledge:

the configuration is done through the Cloud UI.

Good question: @angorayc do you know?

99% just the config value

Yes

Only serverless.

I think the overrides changes the capabilities, right? We're here trying to not even register the feature which makes the corresponding RBAC privileges not even visible for the user.

Hey @azasypkin, thanks for taking a look. Sorry that this line is outdated, I should have removed this continue;, it's no longer needed. In the previous approach that I implemented I was skipping the registration of the siem/siemV2 feature when the new tier was enabled, in the current approach this feature is always registered, just with a different configuration for this new tier.

I vaguely remember that dynamic configuration was only possible in Elastic Cloud (or even only in Serverless?), where the configuration flag for the current tier lived in the Kibana config and was managed by infra (controller?). Is that still the case? If so, is there any reason the code that changes the tier config in the Kibana config couldn’t also alter overrides in the config?

You have a good memory. That's right. In serverless, we use the project controller to create the tiers and roles configuration that we read from Kibana. This approach worked well, and I think we should follow a similar approach. However, I think we should be careful and try to minimize the cross-repo dependencies we introduce, they have become problematic in different ways for the predefined role definitions: we have to keep duplicates in Kibana which are confusing and hard to maintain in sync with the production configs.

I think we should be able to keep the single source of truth inside Kibana, and use the project-controller as the decision maker. I was thinking about having a yaml file with different definitions of the features overrides, one per tier, or maybe having one file per tier would also make sense (e.g. security.essentials.override.yml, security.complete.overrides.yml...), inside Kibana. And the project-controller somehow applies one of them depending on the current tier. Or maybe Kibana itself should pick the correct override config, using the tiers config that is already provided by the project-controller.

wdyt?

cc @YulNaumenko

in the current approach this feature is always registered, just with a different configuration for this new tier.

Aha, good to know. That should definitely simplify things.

However, I think we should be careful and try to minimize the cross-repo dependencies we introduce, they have become problematic in different ways for the predefined role definitions: we have to keep duplicates in Kibana which are confusing and hard to maintain in sync with the production configs.

Agree. The only reason I mentioned controller is that I thought you were skipping the feature registration completely, and hence it would make sense for controller to remove overrides for the feature that doesn’t exist from the config as well. But since you changed your approach, we don’t need to do that.

I think we should be able to keep the single source of truth inside Kibana, and use the project-controller as the decision maker. I was thinking about having a yaml file with different definitions of the features overrides, one per tier, or maybe having one file per tier would also make sense (e.g. security.essentials.override.yml, security.complete.overrides.yml...), inside Kibana. And the project-controller somehow applies one of them depending on the current tier. Or maybe Kibana itself should pick the correct override config, using the tiers config that is already provided by the project-controller.
Here’s the proofread version of your text:

If I understand your current approach correctly, you’re just changing the feature definition at runtime depending on the tier. If so, it sounds much easier than doing this via the configuration like we did with feature overrides. If it fully works for you and doesn't require any nasty hacks (?), I think it’s better to keep what you have, but let’s discuss this during our sync later today to make sure I’m not missing anything.

@azasypkin

If I understand your current approach correctly, you’re just changing the feature definition at runtime depending on the tier. If so, it sounds much easier than doing this via the configuration like we did with feature overrides. If it fully works for you and doesn't require any nasty hacks (?), I think it’s better to keep what you have, but let’s discuss this during our sync later today to make sure I’m not missing anything.

Great! glad that you like the idea, but that's only for Security features.
The missing part is with other features outside the Security plugin, that we also need we need to disable/hide for this tier, such as Fleet, Osquery...
This is what we want to discuss with you, the proposal of having a different override configuration per tier is meant to solve this.

azasypkin · 2025-03-04T13:20:19Z

(tagging myself for review to provide preliminary feedback)

…tier_navigation_v2

tomsonpl · 2025-03-04T15:19:04Z

x-pack/solutions/security/plugins/security_solution_serverless/server/product_features/index.ts

-    configurator.timeline = getTimelineProductFeaturesConfigurator(enabledProductFeatureKeys);
-    configurator.notes = getNotesProductFeaturesConfigurator(enabledProductFeatureKeys);
+
+    // timeline and notes are not available for the searchAiLake tier within Security


Leaving this here so we do not forget:

With this config:

{ product_line: 'security', product_tier: 'search_ai_lake' }, { product_line: 'ai_soc', product_tier: 'search_ai_lake' },

we should not see timelines, notes, and siem_migration.

@ashokaditya This is why we talked about not registering them in the first place (approach 2). You did the approach 1 with capabilities.
Does the trick for the most parts but not all :P
What do you think? 👍

azasypkin · 2025-03-05T12:59:34Z

x-pack/solutions/security/packages/features/src/security/v1_features/kibana_features.ts

@@ -104,21 +104,6 @@ export const getSecurityBaseKibanaFeature = ({
      },
      app: [APP_ID, CLOUD_POSTURE_APP_ID, CLOUD_DEFEND_APP_ID, 'kibana'],
      catalogue: [APP_ID],
-      api: [


question: I’m not familiar enough with the mechanics here or whether these API privileges are needed, but we’re not making a breaking change for users who have roles with this privielge, right?

To best of my knowledge, this is safe. We are just moving these privileges to product_feature_config which also add's the possibility to be run against PLI configuration.
CC: @semd

Yup, this is safe. We are just moving things around to make them tier-dependent.

All existing tiers will have these privileges configured with the same API/UI actions as currently.

The new tier will have these privileges configured with a new set of API/UI actions specific to this tier.

Roger that, thanks for clarifying!

azasypkin · 2025-03-05T14:42:49Z

x-pack/platform/plugins/shared/features/server/feature_registry.ts

@@ -108,6 +108,7 @@ export class FeatureRegistry {
    for (const [featureId, featureOverride] of Object.entries(overrides)) {
      const feature = this.kibanaFeatures[featureId];
      if (!feature) {
+        continue;


I have a few questions to better understand what you’re trying to achieve:

What is the process for changing the product tier/line?

Is it something a user can do themselves?

Is the current tier stored somewhere in ES, or is it a config value?

Does the change require a Kibana restart?

In which offerings is it possible to dynamically update tiers/lines (ECH, ECS, on-prem)?

I vaguely remember that dynamic configuration was only possible in Elastic Cloud (or even only in Serverless?), where the configuration flag for the current tier lived in the Kibana config and was managed by infra (controller?). Is that still the case? If so, is there any reason the code that changes the tier config in the Kibana config couldn’t also alter overrides in the config?

tomsonpl

Thanks @azasypkin,
These are great questions, I tried to answer to the best of my knowledge, however also cc'ying @semd since he's the great mind behind this approach.

tomsonpl · 2025-03-05T15:10:09Z

x-pack/solutions/security/packages/features/src/security/v1_features/kibana_features.ts

@@ -104,21 +104,6 @@ export const getSecurityBaseKibanaFeature = ({
      },
      app: [APP_ID, CLOUD_POSTURE_APP_ID, CLOUD_DEFEND_APP_ID, 'kibana'],
      catalogue: [APP_ID],
-      api: [


To best of my knowledge, this is safe. We are just moving these privileges to product_feature_config which also add's the possibility to be run against PLI configuration.
CC: @semd

tomsonpl · 2025-03-05T15:13:42Z

x-pack/platform/plugins/shared/features/server/feature_registry.ts

@@ -108,6 +108,7 @@ export class FeatureRegistry {
    for (const [featureId, featureOverride] of Object.entries(overrides)) {
      const feature = this.kibanaFeatures[featureId];
      if (!feature) {
+        continue;


To the best of my knowledge:

the configuration is done through the Cloud UI.

Good question: @angorayc do you know?

99% just the config value

Yes

Only serverless.

I think the overrides changes the capabilities, right? We're here trying to not even register the feature which makes the corresponding RBAC privileges not even visible for the user.

tomsonpl · 2025-03-05T15:42:11Z

x-pack/solutions/security/plugins/security_solution_serverless/server/product_features/index.ts

@@ -53,27 +48,21 @@ export const registerProductFeatures = (
  // Cases are always enabled (both for security and AI-SOC)
  configurator.cases = getCasesProductFeaturesConfigurator(enabledProductFeatureKeys);

-  if (productLines[ProductLine.security]) {
-    // TODO: clarify what happens with siem migrations
+  if (productLines[ProductLine.security] && !productTiers[ProductTier.searchAiLake]) {


I wouldn't hide Security fully, just the timelines and notes (oh an siem_migrations). Because now if the config is:

{ product_line: 'security', product_tier: 'search_ai_lake' }, { product_line: 'ai_soc', product_tier: 'search_ai_lake' },

We won't have security.

tomsonpl · 2025-03-05T15:42:13Z

x-pack/solutions/security/plugins/security_solution_serverless/server/product_features/index.ts

  }

-  if (productLines[ProductLine.aiSoc]) {
+  if (productLines[ProductLine.aiSoc] && productTiers[ProductTier.searchAiLake]) {


I think this is not necessary, moreover would block us from using this with higher tiers.

semd added 5 commits February 21, 2025 18:03

example implementation

7921a29

rename

ea0fcac

push ai vav instead of replacing

de6ec7a

Merge remote-tracking branch 'upstream/main' into soc_tier_navigation

9ac7f42

approach disabling siem feature

833c7d0

semd self-assigned this Feb 27, 2025

semd added 2 commits February 27, 2025 14:53

restore unnecessary changes

32b050e

approach 1 security feature, approach 2 the rest

8199a41

semd commented Feb 28, 2025

View reviewed changes

tomsonpl and others added 6 commits March 3, 2025 12:36

rename minimal to searchAILake

e41be37

fix

a6b4a4a

tier rename from minimal to search_ai_lake

0d03da4

move externalDetections, refactor attachedPages, show fleet in Ai_soc

a5c600f

exclude timeline and notes from searchAiLake tier

64688d6

cleanup redundant code

b0c6952

azasypkin self-requested a review March 4, 2025 13:19

tomsonpl added 2 commits March 4, 2025 14:59

add knowledgeSource

854e8b9

Merge remote-tracking branch 'sergi/soc_tier_navigation_v2' into soc_…

909071f

…tier_navigation_v2

tomsonpl reviewed Mar 4, 2025

View reviewed changes

add ai for the soc icon

aed1d0d

azasypkin reviewed Mar 5, 2025

View reviewed changes

fix icon

db2d3ef

tomsonpl reviewed Mar 5, 2025

View reviewed changes

ashokaditya added 2 commits March 5, 2025 16:30

fix feature exclusions on aiSearchLake tier

16227e3

remove redundant configs for notes/timelines

1fb344c

tomsonpl reviewed Mar 5, 2025

View reviewed changes

get rid of continue;

c985210

ashokaditya and others added 2 commits March 6, 2025 12:42

fix import

4a28290

add a whitelisted array of elements in the ai soc navigation

08956d4

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Security Solution][PoC] AI 4 SOC navigation approach 2 #212652

[Security Solution][PoC] AI 4 SOC navigation approach 2 #212652

semd commented Feb 27, 2025 •

edited by ashokaditya

Loading

elasticmachine commented Feb 27, 2025

semd Feb 28, 2025

azasypkin Mar 5, 2025

tomsonpl Mar 5, 2025

semd Mar 5, 2025

azasypkin Mar 6, 2025

semd Mar 6, 2025

azasypkin commented Mar 4, 2025

tomsonpl Mar 4, 2025 •

edited

Loading

azasypkin Mar 5, 2025

tomsonpl Mar 5, 2025

semd Mar 5, 2025

azasypkin Mar 6, 2025

azasypkin Mar 5, 2025

tomsonpl left a comment

tomsonpl Mar 5, 2025

tomsonpl Mar 5, 2025

tomsonpl Mar 5, 2025 •

edited

Loading

tomsonpl Mar 5, 2025

[Security Solution][PoC] AI 4 SOC navigation approach 2 #212652

Are you sure you want to change the base?

[Security Solution][PoC] AI 4 SOC navigation approach 2 #212652

Conversation

semd commented Feb 27, 2025 • edited by ashokaditya Loading

Summary

Screenshots

Security + AI

Left nav

Custom roles creation

Only AI

Left nav

Custom role creation

Only security

Left nav

Custom role creation

elasticmachine commented Feb 27, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azasypkin commented Mar 4, 2025

tomsonpl Mar 4, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tomsonpl left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tomsonpl Mar 5, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

semd commented Feb 27, 2025 •

edited by ashokaditya

Loading

tomsonpl Mar 4, 2025 •

edited

Loading

tomsonpl Mar 5, 2025 •

edited

Loading