Add support for a declarative (via configuration) way to specify Kibana feature overrides

[azasypkin]

Summary

This PR extends the features plugin to accept feature definition overrides via Kibana configuration. The functionality is limited to the Serverless offering only. Additionally, the PR updates Kibana serverless configurations to include overrides based on the "simplified feature toggles" proposals discussed with the solution teams.

The configuration might look like this:

## Fine-tune the feature privileges.
xpack.features.overrides:
  dashboard:
    privileges:
      ### Dashboard's `All` feature privilege should implicitly
      ### grant `All` access to Maps and Visualize features.
      all.composedOf:
        - feature: "maps"
          privileges: [ "all" ]
        - feature: "visualize"
          privileges: [ "all" ]
    ### All Dashboard sub-feature privileges should be hidden: 
    ### reporting capabilities will be granted via dedicated
    ### Reporting feature and short URL sub-feature privilege
    ### should be granted for both `All` and `Read`.
    subFeatures.privileges:
      download_csv_report.disabled: true
      url_create:
        disabled: true
        includeIn: "read"
  ### Maps feature is disabled since it's automatically granted by Dashboard feature.
  maps.disabled: true

How to test

Log in as the admin using SAML and navigate to the Custom roles management section to edit role and see tuned role management UX:

Search project

yarn es serverless --projectType=es --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=es --ssl --xpack.security.roleManagementEnabled=true

Refer to the proposal document, config/serverless.yml, and config/serverless.es.yml in this PR to see the specific changes made for your project type:

Create a custom custom-search role and re-login as the user with this role to test your project type (you need to manually type role name if the role selector):

Observability project

yarn es serverless --projectType=oblt --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=oblt --ssl --xpack.security.roleManagementEnabled=true

Refer to the proposal document, config/serverless.yml, and config/serverless.oblt.yml in this PR to see the specific changes made for your project type:

Create a custom custom-o11y role and re-login as the user with this role to test your project type (you need to manually type role name if the role selector):

Security project

yarn es serverless --projectType=security --ssl -E xpack.security.authc.native_roles.enabled=true
yarn start --serverless=security --ssl --xpack.security.roleManagementEnabled=true

Refer to the proposal document, config/serverless.yml, and config/serverless.security.yml in this PR to see the specific changes made for your project type:

Create a custom custom-security role and re-login as the user with this role to test your project type (you need to manually type role name if the role selector):

Fixes: https://github.com/elastic/kibana/issues/178963

[azasypkin]

/ci

[azasypkin]

/ci

[azasypkin]

/ci

[azasypkin]

/ci

[azasypkin]

Hey @legrego, the PR should be ready for review whenever you have time! I'm not opening it for a wider review just yet because I want to make sure we agree with the approach within our team first. I'm also considering adding more API integration tests.

[azasypkin]

/ci

[azasypkin]

/ci

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[azasypkin]

Hey @semd, @andrewvc, and @jimczi I'm tagging you for review of solution-specific changes in Security, Observability, and Search, respectively. These changes are based on the "Feature Toggle Proposal" documents that you've been reviewing recently.

@elastic/appex-sharedux or @elastic/kibana-reporting-services can you please review the changes in the Reporting plugin?

@elastic/kibana-core I'd appreciate your input for the changes in the Features plugin (these are supposed to be serverless-only at this stage).

The How to test section of the PR description includes the necessary steps to test the changes https://github.com/elastic/kibana/pull/180362#issue-2233335823, but let me know if you have any questions.

Thanks!

[azasypkin]

/ci

[kibana-ci]

:green_heart: Build Succeeded

• Buildkite Build
• Commit: 67a14cb23c17be06f72869defb6aa12ad93259ad
• Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-180362-67a14cb23c17
• Security Deployment

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
features	99	102	+3

Async chunks

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

id	before	after	diff
security	564.8KB	565.1KB	+322.0B

Canvas Sharable Runtime

The Canvas "shareable runtime" is an bundle produced to enable running Canvas workpads outside of Kibana. This bundle is included in third-party webpages that embed canvas and therefor should be as slim as possible.

id	before	after	diff
module count	-	5407	+5407
total size	-	8.8MB	+8.8MB

Page load bundle

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

id	before	after	diff
features	3.6KB	3.7KB	+43.0B

Unknown metric groups

API count

id	before	after	diff
features	235	247	+12

References to deprecated APIs

id	before	after	diff
security	37	46	+9

History

• :green_heart: Build #207781 succeeded ba7a792063986d8c3eeeada6ba839f3fca22702c
• :green_heart: Build #207774 succeeded 6908d2fce30f6df6b25eb0303bf69379b8c40548
• :green_heart: Build #206421 succeeded 82995cea6d7dd0a5279eb308ea06e715f25a36e4
• :yellow_heart: Build #205689 was flaky 524348b4c5b45d1aee5e281827f8929ca0fee8d6
• :green_heart: Build #204948 succeeded 317e33a20f92ed586163bdbc391ce66cfd38e560

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

cc @azasypkin

[semd]

Hi @azasypkin this looks great, thanks for this fantastic work. I have been reviewing and testing it and the main parts are working as expected. However, I've noticed an interesting behavior with the disabled flag:

I tested disabling the securitySolutionCases feature to see how the app behaves.

Before making any change

Accessing the Security application using the Editor role (which has feature_securitySolutionCases.all enabled), the Cases privileges are granted, and the /api/core/capabilities response is:

The Cases page is accessible and the link appears in the navigation, as expected:

When I add the securitySolutionCases.disabled: true override

I see that when accessing the application with Editor role, the Cases capabilities are no longer granted, which is the behavior I would expect. The /api/core/capabilities response is:

So, the Cases page in security is not accessible and the link in the navigation does not show up, as expected:

However, (that's the interesting part) when I access the application using Admin role, Cases is enabled again, the /api/core/capabilities response has all the securitySolutionCases privileges set to true, and the Cases page is usable again, which was not expected. Since this is a project config, I would expect consistent behavior when securitySolutionCases.disabled: true for all the roles, including Admin.

I would bet the explanation has something to do with how ES processes admin (*) roles, but I haven't tested that. What do you think? Am I missing something?

[azasypkin]

I would bet the explanation has something to do with how ES processes admin (*) roles, but I haven't tested that. What do you think? Am I missing something?

@semd thanks a lot for providing detailed steps, looking into this right now!

[azasypkin]

Okay, @semd, here's where I believe the confusion is coming from and why using "feature" and "disable" naming is problematic, but we had to stick with them for consistency's sake. Let me start from the beginning:

As a Kibana developer, you develop some "functionality" (UIs, APIs, and corresponding Saved Objects), for example, the Case application and APIs. Then, if you'd like to establish role-based access controls (RBAC) for this "functionality", you introduce a "feature" that describes the required access profile for this "functionality", for instance, a "feature" with the securitySolutionCases ID.

Let's refer to this "feature" as "functionality access profile" or just "access profile", which better describes what it is in reality. The "access profile" provides you with different mechanisms and hooks you can use in your code to associate certain "functionality" with that profile (API access tags, UI capabilities, and so on).

If your "functionality" surface is large enough and you'd like to have a more fine-grained RBAC, you might want to introduce multiple "access profiles" via "sub-features" within your "feature" or even multiple separate "features". The "access profile" is purely a security control, and its purpose is to allow administrators to combine required "access profiles" for different "functionalities" to create a role for the user while modeling RBAC based on the organization's requirements. With this, admins might allow only some users to access certain "functionality".

Now, let's consider three different scenarios:

1. You decide that some "functionality" should be available to all users irrespective of their permissions. It's a deployment-level security decision, and the correct way to do that is to stop registering the "access profile"/"feature" altogether.

2. You decide that some "functionality" should NOT be available to all users irrespective of their permissions. It's a deployment-level functionality decision, and the correct way to do that is to disable "functionality" completely (e.g., disable the plugin or part of it), and as a consequence, the "access profile"/"feature" won't be registered as well.

3. You decide that some "functionality" should still be available to some users, but you don't want admins to deal with the specific "access profile"/"feature" explicitly. It's a role-level security decision. The correct way to do that is to keep the "functionality" enabled and only hide its "access profile" in the role management UIs, e.g., set features.overrides.securitySolutionCases.disabled: true in config overrides.

The third scenario is the one you tried, let's take a closer look. There are two cases why you'd want to keep "functionality" enabled but prevent admins from explicitly dealing with its "access profile": you either want to implicitly include the "access profile" in another "access profile" (via composedOf override), or you want to automatically grant this "access profile" only to those users who should have access to all "functionality" regardless of their "access profiles" - admins, superusers, and any other roles with * in their application role definitions. The latter is what you observe.

So you were right that the reason why built-in Admin could still access Cases functionality was that they had * (all) access to all "functionalities" in Kibana regardless of their "access profiles" (existing or future). I know it's not trivial, and the legacy naming makes things even more confusing, but does my explanation make sense to you?

[semd]

Hey @azasypkin, yes the names may be the cause of the confusion, the disable flag is a bit misleading. Thanks for the detailed explanation, it raised another question though (I'll try to follow the same naming convention you used):

3. You decide that some "functionality" should still be available to some users, but you don't want admins to deal with the specific "access profile"/"feature" explicitly. It's a role-level security decision. The correct way to do that is to keep the "functionality" enabled and only hide its "access profile" in the role management UIs, e.g., set features.overrides.securitySolutionCases.disabled: true in config overrides.

From what I tested, in this scenario, we are making the "functionality" available only to admin (* / "all enabled") users. So, along with hiding that from the role management UI, it also changes the behavior for all non-admin roles, becoming unavailable for them, no matter how their role is defined (assuming I didn't miss anything while testing it). And this behavior is static, no user can change that dynamically when an "access profile"/"feature" has been disabled, that's why I assumed this was a product-level functionality decision, not at a role-level, maybe that's also where the misunderstanding comes from.

Nevertheless, it's hard for me to imagine a scenario in which we would want to apply this behavior. Like this change for stackAlerts: https://github.com/elastic/kibana/blob/67a14cb23c17be06f72869defb6aa12ad93259ad/config/serverless.security.yml#L48-L49 Do we still want admin users to have the stackAlerts "access profile"/"feature" available, if that "functionality" falls outside a Security serverless project?

[azasypkin]

From what I tested, in this scenario, we are making the "functionality" available only to admin (* / "all enabled") users. So, along with hiding that from the role management UI, it also changes the behavior for all non-admin roles, becoming unavailable for them, no matter how their role is defined (assuming I didn't miss anything while testing it). And this behavior is static, no user can change that dynamically when an "access profile"/"feature" has been disabled, that's why I assumed this was a product-level functionality decision, not at a role-level, maybe that's also where the misunderstanding comes from.

Yeah, it's a bit tricky, if you decide to hide the "access profile" for the "functionality" in the role management UIs, all existing non-admin roles behave as if they weren't granted this "access profile"/"feature" in the first place, to be consistent with all new roles that won't be able to get it since it's not available in the UI and API. After we enable custom roles, this is supposed to be a breaking change unless you're providing role/privilege migration (once we have them) to give users equivalent "access profile" through other means.

Nevertheless, it's hard for me to imagine a scenario in which we would want to apply this behavior.

Right, the main use case for hiding "access profiles" for enabled "functionalities" is to implicitly include them into other "access profiles" through the composedOf override to simplify the role management experience. If that's not the goal, then usually the right solution is to disable the "functionality" completely, not just their "access profile".

I think a large chunk of the confusion originates from the fact that wildcard roles (admins, superusers) are quite special in Elasticsearch.

Do we still want admin users to have the stackAlerts "access profile"/"feature" available, if that "functionality" falls outside a Security serverless project?

I guess it's a good product question and depends on what you want. In the proposal, Stack Rules is marked as Safe to remove from the Role Management UI, but what does it mean for the Security project type? I'm not very familiar with stackAlerts (Stack Rules), is the same "access profile" granted by something else that makes this unnecessary in the Role Management UI, or was it marked as Safe to remove by mistake?

[semd]

@azasypkin

Right, the main use case for hiding "access profiles" for enabled "functionalities" is to implicitly include them into other "access profiles" through the composedOf override to simplify the role management experience. If that's not the goal, then usually the right solution is to disable the "functionality" completely, not just their "access profile".

Great! This resolves my last question. Then I believe we only want to set disabled to features that are also composedOf, and disable stackAlerts functionality completely instead of hiding the "access profile"/"feature". Let me get confirmation from our PM, and I'll let you know.

Thanks for taking the time to answer the questions.

[azasypkin]

Great! This resolves my last question. Then I believe we only want to set disabled to features that are also composedOf, and disable stackAlerts functionality completely instead of hiding the "access profile"/"feature". Let me get confirmation from our PM, and I'll let you know.

Thanks @semd! We're also adding ourselves as reviewers for the serverless configs to better understand how teams will want to use these overrides over time, what might still be missing or confusing, and also to advise on options depending on the use case.

[azasypkin]

/ci

[sophiec20]

Will the Machine Learning privilege give us everything we need for the Observability AI Ops app in serverless? Are there other features that Machine Learning privilege controls within observability outside of the AI Ops app? If not, we'd prefer to "rename" this AI Ops to match with our information architecture and navigation. Also, is there any features we lose now that Machine Learning has been moved outside of the management section and into Observability?

The ML privileges allow use of anomaly detection, data frame analytics, trained models and AIOps features in elasticsearch and in kibana. Some of these features are disabled for O11y serverless.

The ML privileges have related elasticsearch privileges manage_ml and monitor_ml .. and related Kibana APIs. It is more than just a label in a UI. In order to have easier support and easier documentation, it's preferable to keep the Machine Learning privilege name. If we rename privileges for platform components, it adds potential confusion as we context switch between solutions.

[azasypkin]

Thanks for the feedback @dominiqueclarke. Please, see my replies and questions below:

1. APM & User Experience needs to be renamed Applications, Synthetics & Uptime needs to be renamed Synthetics and Metrics needs to be renamed Infrastructure.

Do I understand correctly that you'd like to rename these only in Serverless and keep the old names in other offerings? If yes, I can do that in this PR, sure. If not, and your plan is to rename them everywhere, then you'd better do it directly during feature registrations, as config overrides isn't the right tool for that.

My understanding is that renaming a privilege is basically impossible given the reasons specified here. Does a new privilege need to be created that is "composed of" via the new composedOf option? Or is there some other type of migration path we should following for introducing this new/renamed privilege?

The doc you linked to refers to changing feature programmatic identifiers, which is a breaking change. But if I understand you correctly, you only want to change user-facing feature names/labels, which isn't a breaking change. Even though the new names might confuse admins, they don't change anything from a security perspective.

2. What is the Logs privilege meant to control now that Discover has been moved into Observability to replace logs? Will embedded logs components inside of APM no longer work without this privilege? Is there anything else that the Logs privilege controls in serverless? How do we communicate to users the differences between the Logs and Discover role in the serverless context?

I assume this question is for the Logs team as I have no idea 🙂 Tagging @weltenwort to help with that.

3. What does the Observability role control? It's quite confusing to have an Observability role under the Observability dropdown. Is this for the Observability overview page, which doesn't exist in serverless?

Same as for question 2, the Observability feature in Observability category is defined by observability plugin in https://github.com/elastic/kibana/blob/742dff0f222af55d1a8156e6d32bd22e2302a141/x-pack/plugins/observability_solution/observability/server/plugin.ts#L227-L228 and governed by createO11yGenericFeatureId configuration flag which is explicitly enabled in Serverless config. Tagging @XavierM who added this flag for Serverless O11y solution.

That being said, I agree, the naming is confusing, but it's confusing everywhere, not just in Serverless.

4. Will the Machine Learning privilege give us everything we need for the Observability AI Ops app in serverless? Are there other features that Machine Learning privilege controls within observability outside of the AI Ops app? If not, we'd prefer to "rename" this AI Ops to match with our information architecture and navigation.

Thanks for providing context @sophiec20. I also agree with keeping the old Machine Learning name, considering that we still have Machine Learning in other project types, and we have only one set of docs that explain what the Machine Learning privilege is about and how to configure it.

Also, is there any features we lose now that Machine Learning has been moved outside of the management section and into Observability?

No, it's purely a UI/visual change.

5. Files Management and Shared Images: Why is this needed? Is it related to cases?

Tagging @jloleysens to clarify whether and why you might or might not need this in Serverless. Related APIs and UIs are quite generic/at the platform level, I'm not sure what functionality relies on them exactly.

6. Tags Management: Why would I need this? Can it be rolled up in the Saved Object Management privileges?

You'd need this to allow users to view and edit Saved Object tags. Saved Object Management is much more powerful, you certainly don't want to give it to the users just to let them manipulate tags. Even though we're considering granting read access to Saved Object tags to all users (outside the scope of this PR and might never happen), we'll likely still need a dedicated privilege to allow users to create, edit, or delete tags.

7. Would users find OsQuery Saved Queries privilege and the Saved Queries privilege confusing?

I don't know, would they? 🙂 I think, it's a perfect question for your product and UX teams.

Cases was previously in the management section and has now been moved under Observability. Does this prevent us from doing anything?

Hhhm, nope, Cases feature is originally registered under Observability category, see https://github.com/elastic/kibana/blob/df74eb609ce66f5a3da3362ec0acdf410789e480/x-pack/plugins/observability_solution/observability/server/plugin.ts#L105-L111. I assume we have multiple different Cases features...

[weltenwort]

What is the Logs privilege meant to control now that Discover has been moved into Observability to replace logs? Will embedded logs components inside of APM no longer work without this privilege? Is there anything else that the Logs privilege controls in serverless? How do we communicate to users the differences between the Logs and Discover role in the serverless context?

We have not made any change to the existing Logs UI and Logs Stream embeddable. They will be phased out when the roadmap allows for it. Before we do that we'll provide replacements for the usage sites of the old components.

The new Discover-based Logs Explorer relies on Discover, Fleet and index privileges as documented.

Does that help?

[dominiqueclarke]

What is the Logs privilege meant to control now that Discover has been moved into Observability to replace logs? Will embedded logs components inside of APM no longer work without this privilege? Is there anything else that the Logs privilege controls in serverless? How do we communicate to users the differences between the Logs and Discover role in the serverless context?

We have not made any change to the existing Logs UI and Logs Stream embeddable. They will be phased out when the roadmap allows for it. Before we do that we'll provide replacements for the usage sites of the old components.

The new Discover-based Logs Explorer relies on Discover, Fleet and index privileges as documented.

Does that help? @weltenwort It does. What is your opinion on keeping this privilege in serverless? Is it needed?

Just to be be clear, the existing Logs UI will not be available in serverless, is that correct?

But APM will be, which uses the Logs Stream Embeddable. Should we prioritize phasing out the Logs Stream embeddable in APM so that we can remove this privilege from serverless entirely without broken experiences in APM?

[weltenwort]

Just to be be clear, the existing Logs UI will not be available in serverless, is that correct?

that is correct

But APM will be, which uses the Logs Stream Embeddable. Should we prioritize phasing out the Logs Stream embeddable in APM so that we can remove this privilege from serverless entirely without broken experiences in APM?

APM is not the only consumer IIRC. not sure where on our roadmap a replacement is. @gbamparop can you make any statement about that?

[lukeelmers]

I just wanted to jump in with a naive question before we merge this - I'm guessing that the main reason for these xpack.features yml configs being "aware" of the different features that are registered is because that's what we are doing from the features plugin in buildOSSFeatures.

But I wonder if this PR isn't just adding to our technical debt in this area? This is a lot of yml boilerplate to add to the serverless config files, and the fact that we are adding the team as codeowners to that file tells me we already think this is something that's easy to mess up and break.

Should we instead be thinking about making this decision at the plugin level? That is, breaking up the oss_features.ts and conditionally calling registerKibanaFeature from those individual plugins depending on whether we are in serverless or not? To me, this seems like one situation where an isServerless-type check might be warranted, especially if it means allowing the features service to be simpler and know less about the rest of Kibana. This would also lend itself well to eventually moving features into core if we choose to do so.

I'm sure I am missing a bunch of context here, so maybe we can discuss this more in one of the weekly tech syncs or elsewhere?

[azasypkin]

Thanks for sharing your concerns @lukeelmers!

I'm guessing that the main reason for these xpack.features yml configs being "aware" of the different features that are registered is because that's what we are doing from the features plugin in buildOSSFeatures.

Nope, not really. I'm out this week, but let me give you a bit more context next week on why we're doing this and why I believe we shouldn't try to make this decision at the plugin level, or even in code. We can discuss it during our sync on Monday and, if needed, move the discussion to a broader group.

we are adding the team as codeowners to that file tells me we already think this is something that's easy to mess up and break.

We're adding this to learn more about the use cases and as an opportunity to teach what is possible before we have comprehensive docs to refer folks to. It doesn't seem we have any other effective way or forum to do that today.

[jloleysens]

@dominiqueclarke @azasypkin

Tagging @jloleysens to clarify...files management

I believe this is used by cases, yes. But as Oleg mentioned this is a generic feature that could be used in any solution that needs to store files and also manage them. Let me know if I didn't answer the q or need missed something!

[azasypkin]

Okay, here's the additional context and my thoughts on this change, @lukeelmers. Sorry in advance for the wall of text!

I just wanted to jump in with a naive question before we merge this - I'm guessing that the main reason for these xpack.features yml configs being "aware" of the different features that are registered is because that's what we are doing from the features plugin in buildOSSFeatures.

The main purpose of the features plugin is to be aware of all registered Kibana features, validate feature configurations, and serve as a central point to expose this information to all interested parties (e.g., Security, Alerting, and Cases). This applies to both OSS features registered via buildOSSFeatures and features registered by x-pack plugins themselves (featuresSetupContract.registerKibanaFeature). At this point, buildOSSFeatures is probably an old workaround that we should get rid of now that OSS plugins can depend directly on the X-Pack features plugin.

But I wonder if this PR isn't just adding to our technical debt in this area? This is a lot of yml boilerplate to add to the serverless config files, and the fact that we are adding the team as codeowners to that file tells me we already think this is something that's easy to mess up and break.

Would you mind clarifying what technical debt you mean? Based on the feedback we received from Solutions, there is an appetite to customize and consolidate the Kibana role management experience on multiple dimensions at the same time: at the offering level (e.g., stateless vs. serverless), at the solution level (e.g., security vs. observability projects), and eventually, at the solution-specific subscription tier level. This last point is mainly based on feedback from the Security solution, and it's too early to consider this a real use case at this point, but it gives a sense of the direction we're likely moving towards. This means that this functionality isn't temporary and should exist in one form or another.

What we're experimenting with here is the exact form (declarative, via configuration) in which we're exposing these capabilities to solutions. We might change the form along the way, but we need to start with something that feels reasonable and is easy to change if needed. Historically, we have tried to do everything in code. This has its benefits and is usually easier to implement, but I'd like to challenge this approach in this specific case. A declarative configuration approach might be perceived as too wordy or boilerplate, but I think that's because we don't hide the vast nature of the required overrides in code by spreading it over multiple plugins.

Should we instead be thinking about making this decision at the plugin level? That is, breaking up the oss_features.ts and conditionally calling registerKibanaFeature from those individual plugins depending on whether we are in serverless or not? To me, this seems like one situation where an isServerless-type check might be warranted, especially if it means allowing the features service to be simpler and know less about the rest of Kibana. This would also lend itself well to eventually moving features into core if we choose to do so.

We've considered making these decisions at the plugin level, but the drawbacks are quite significant. Let's use the Discover plugin and its corresponding feature as an example. Here's what we need:

• In ESS/ECE/On-Prem, Discover should stay as a standalone feature in role management. It should only grant access to Discover specific functionalities and provide several additional sub-feature privileges (e.g., stored sessions or short URLs). It should be part of the Analytics privileges group and shouldn't allow users to create short URLs unless the administrator explicitly grants a dedicated Short URLs sub-feature privilege.
• In Serverless, for all solutions/project types, the Discover feature shouldn't expose any sub-feature privileges.
• In Serverless, for all solutions/project types, granting Discover access should automatically allow users to create short URLs, and administrators shouldn't be allowed to change this.
• In Serverless, for the Search solution/project type only, Discover should move from the Analytics privileges group to the Search privileges group.
• In Serverless, for the Security solution/project type only, Discover should be completely hidden since it should be automatically granted by the SIEM feature.
• In Serverless, for the Observability solution/project type only, Discover should move from the Analytics privileges group to the Observability privileges group.
• In Serverless, for the Observability solution/project type only, Discover should additionally grant access to certain observability-specific functionalities.

As you can see, these decisions don't really belong to Discover. It is essentially a context-agnostic but configurable building block for the solutions that own these decisions.

Now, this is just for Discover, but we have a number of similar requirements for other OSS and X-Pack features. If we try to implement this logic in every such plugin, we'll completely lose visibility into how role management UX is supposed to work in each context. This won't only make auditing infeasible but will likely lead to subtle bugs. Bugs in security area are vulnerabilities most of the time.

That's why I believe we should make these overrides as centralized as possible. If we agree, then the next question is what this central place or "orchestrator" should look like. It can either be the features plugin or project-type specific serverless plugins, and it can either be hard-coded or described in a declarative manner via offering and solution specific configuration.

I have some reservations on why configuration is at least not worse, but likely better than hard-coding logic in plugins, especially in orchestrated, configuration-heavy environments like Kubernetes with all our custom controllers. I don't want to divert from the main point of contention at this time, but I'm happy to share my thoughts on this as well!

We understand that there is a risk that things will not go as smoothly as we expect. That's why, for now, we're scoping this to Serverless only and not allowing plugins to make overrides outside of the central configuration.

Does that make sense to you? What do you think?

[gbamparop]

APM is not the only consumer IIRC. not sure where on our roadmap a replacement is. @gbamparop can you make any statement about that?

This is something that we're planning to do but we don't have timelines yet. When the component is replaced, we could update the underlying privileges in applications and Fleet.

[azasypkin]

@elasticmachine merge upstream

[lukeelmers]

@azasypkin and I discussed some of my questions about this PR offline, and came to the following conclusions:

1. We are envisioning these declarative configs as internal, temporary, feature-flag-like settings to allow solution teams to iterate more rapidly on various layouts. The approach taken here is more realistic than pushing logic to each individual plugin. The upside of a config-based strategy is that it is easier to change quickly, but the downside is that the features plugin now needs to have a level of awareness of different features being registered in order to build the config schema.
2. After a period of time, once we see the settings in these configs start to stabilize, we would like to consider moving this into code. In practice, this could look like exposing an API from the features plugin to allow each solution to declaratively specify how they want the features to be overridden (similar to what's done here in yml, just in code instead). It would mean the features plugin doesn't need to know about each of the features being registered, however the solutions would need to know the IDs of the features they want to work with. These IDs could be imported from the plugins which register those features, thus creating a clear tree of dependencies.
3. We do not intend to release this functionality in its current state to ESS, which would risk turning it into more of a one-way door. Before we go down that path, we'd like to first address (2).

--

@azasypkin Please chime in if there's anything important I forgot to mention! 🙂