[Security Solution][Serverless] Create all Security sub-features

[semd]

Summary

When "custom roles" are available in serverless, and without a role migration mechanism, extracting a new sub-feature will result in users assigned to custom roles losing authorization for the feature. This is a known issue that the Platform Security team is aware of.

We will be able to migrate roles eventually, but since then, and after "serverless custom roles" are GA, we won't be able to extract sub-features without causing breaking changes on the Security RBAC.

At the same time, to achieve the desired feature granularity for the serverless predefined roles, we need to extract functionalities into sub-features. Right now the authorization for many of those functionalities is still granted by the general Security Kibana feature.

So, to avoid having to deal with this problem later, we should extract all sub-features we need before custom roles start to be created.

How to extract sub-features

The sub-features we need to create are defined by the Security predefined roles specification.

Each of them needs to have a config on the Security ProductFeatures framework at:

https://github.com/elastic/kibana/blob/main/x-pack/packages/security-solution/features/src/security/kibana_sub_features.ts

It is also important to define the new sub-features with the correct includeIn property, referencing all or read main features, like the endpointExceptions does:

kibana/x-pack/packages/security-solution/features/src/security/kibana_sub_features.ts

Lines 554 to 601 in 1f8c816

	const endpointExceptionsSubFeature: SubFeatureConfig = {
	requireAllSpaces: true,
	privilegesTooltip: i18n.translate(
	'securitySolutionPackages.features.featureRegistry.subFeatures.endpointExceptions.privilegesTooltip',
	{
	defaultMessage: 'All Spaces is required for Endpoint Exceptions access.',
	}
	),
	name: i18n.translate(
	'securitySolutionPackages.features.featureRegistry.subFeatures.endpointExceptions',
	{
	defaultMessage: 'Endpoint Exceptions',
	}
	),
	description: i18n.translate(
	'securitySolutionPackages.features.featureRegistry.subFeatures.endpointExceptions.description',
	{
	defaultMessage: 'Use Endpoint Exceptions (this is a test sub-feature).',
	}
	),
	privilegeGroups: [
	{
	groupType: 'mutually_exclusive',
	privileges: [
	{
	id: 'endpoint_exceptions_all',
	includeIn: 'all',
	name: 'All',
	savedObject: {
	all: [],
	read: [],
	},
	...AppFeaturesPrivileges[AppFeaturesPrivilegeId.endpointExceptions].all,
	},
	{
	id: 'endpoint_exceptions_read',
	includeIn: 'read',
	name: 'Read',
	savedObject: {
	all: [],
	read: [],
	},
	...AppFeaturesPrivileges[AppFeaturesPrivilegeId.endpointExceptions].read,
	},
	],
	},
	],
	};

After defining the sub-feature we need to add it to the Kibana Features config on the serverless plugin:

kibana/x-pack/plugins/security_solution_serverless/server/product_features/security_product_features_config.ts

Lines 48 to 50 in a66d42b

	[ProductFeatureSecurityKey.endpointExceptions]: {
	subFeatureIds: [SecuritySubFeatureId.endpointExceptions],
	},

And configure the predefined roles to include the new privilege (docs)

On the ESS side, we don't want to configure the new sub-feature to avoid breaking existing custom roles. We need to enable the new privilege with the main Security feature, without configuring the new sub-feature:

kibana/x-pack/plugins/security_solution_ess/server/product_features/security_product_features_config.ts

Lines 47 to 49 in a66d42b

	[ProductFeatureSecurityKey.endpointExceptions]: {
	privileges: ProductFeaturesPrivileges[ProductFeaturesPrivilegeId.endpointExceptions],
	},

Tip

We can take the endpointExceptions sub-feature implementation as an example for the other ones

Sub-feature checks in the application

Adding the config will make the sub-features exist in the Kibana features registry, so when custom roles start being created they will be aware of all sub-features, avoiding the need to migrate roles later on.

However, without implementing the checks in the application code, assigning those new sub-features to a custom role will have no effect, authorization will still be given by the general Security feature.

There's no need to implement all the checks in the code at the same time, it can be done separately. But it will need to be done to make the sub-features assignments work properly.

Predefined roles features (at the time of writing)

• User Profile Settings external
• Setup: Cluster privileges (?) external
• Kibana Dashboards (Integrations-included and Custom) external
• Discover external
• Visulize Library (Lens, Maps, Aggregations, Tools) external
• Data Sources (including indicator indicies)
• Security Dashboards
• Explore pages
• Timeline - https://github.com/elastic/security-team/issues/7998
• SIEM ML jobs
• Rules, Alerts, Exceptions, Value lists - https://github.com/elastic/security-team/issues/9533
• Action connectors external
• Rule Actions (Webhook, ITSM, SOAR, etc.)
• Cases
• Case Connectors (webhook, SOAR, ITSM)
• Case Assignment (Collaboration)
• Intelligence / Indicators pages
• Insights (accessible on alert)
• Fleet external
• Integrations
• Agent / Endpoint Tamper protection
• Elastic Defend - integration policy mgmt
• Elastic Defend - Endpoint List (Future: "Asset Management")
• Elastic Defend - Response Actions
• Elastic Defend - artifact management
• Osquery external
• Self-healing (Windows)

[elasticmachine]

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

[elasticmachine]

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

[semd]

@yctercero Since "Alert management" functionalities work differently and they check the alerts index privilege to enable/disable features, we can probably accomplish the desired behavior by setting the correct index privilege to the predefined roles. So we won't need a sub-feature for them.

[paulewing]

@semd per our sync, we can remove Dashboards and Explore pages from the requirement list as they would be consistently available.

[approksiu]

@semd what about Benchmark Rules / Findings?

[semd]

@approksiu I don't see the Benchmark Rules / Findings feature in the predefined roles spreadsheet. Do you think it should be included?

[yctercero]

Hey @semd ! I just wanted to confirm that we do not need the alerts subfeature for Serverless GA as it is a data stream that can be managed through index privileges, correct? If this is the case, then we will concentrate on exceptions and rules subfeature and introduce alerts kibana privilege further down the line when needed.

cc @banderror @peluja1012 @paulewing @approksiu

[banderror]

Updated the description with https://github.com/elastic/security-team/issues/8799 and closed https://github.com/elastic/security-team/issues/8193 /cc @xcrzx

[banderror]

The work on changing Kibana-level privileges for rules, exceptions, value lists, and alerts was put on hold yesterday. The corresponding tickets are:

• https://github.com/elastic/security-team/issues/8799
• https://github.com/elastic/security-team/issues/8192
• https://github.com/elastic/security-team/issues/9105
• https://github.com/elastic/security-team/issues/8191

After research done by @xcrzx and @e40pud and trying to implement this new RBAC, we identified substantial risks we didn't want to be dealing with if we were to release this in Serverless before Public Ungated Preview:

• Complexity of maintaining two different RBAC implementations in ESS and Serverless turned out to be high.
• Development would take more time than we initially expected, and would be done under pressure of the April 30 deadline. We wouldn't be able to meet this deadline.
• We would be making rushed decisions and so potential mistakes that we wouldn't be able to fix without having a migration mechanism for custom roles.
• We wouldn't be able to create a good RBAC UX for alerts and value lists - something that requires index-level privileges in addition to Kibana-level privileges.
• Technical risks in detail: https://github.com/elastic/security-team/issues/8799#issuecomment-2049439950

After multiple discussions between @xcrzx @e40pud @approksiu @yctercero @banderror @peluja1012 @marshallmain @YulNaumenko @MikePaquette, we got a green light from Product and we're putting this on hold until a migration mechanism is developed by the Kibana Security team.

An internal document from @approksiu contains more info. We will proceed with the option 2.1 described in it.