Disabling a space feature impacts privileges

[DBolge]

Kibana version: 8.14.1

Elasticsearch version: 8.14.1

Server OS version: Ubuntu 20.04.6

Browser version: Edge 126.0.2592.81

Browser OS version: Windows 10 22H2

Original install method (e.g. download page, yum, from source, etc.): ECE

Describe the bug: Disabling features in a space impacts the API privileges on that feature. Discovered when trying to delete Data Views from a Space with superuser role.

Steps to reproduce:

1. All actions performed as superuser.
2. Create a space with Data Views disabled:

   POST kbn:/api/spaces/space
   {
   "id": "test",
   "name": "Test-Space",
   "disabledFeatures": [
   "indexPatterns"
   ]
   }

3. In my case Data Views had been added before features were disabled but at this point I can't even create a Data View:

   POST kbn:/s/test/api/data_views/data_view
   {
   "data_view": {
   "title": "logs-*",
   "name": "Logs DV"
   }
   }

Response:

{
  "statusCode": 400,
  "error": "Bad Request",
  "message": "Operation failed due to insufficient access, id: undefined"
}

4. Works fine if the disabled feature is dropped: PUT kbn:/api/spaces/space/test { "id": "test", "name": "Test-Space", "disabledFeatures": [ ] }

Expected behavior: As a superuser I should be able to create and delete Data Views as required for a target space even if the feature is disabled.

Screenshots (if relevant):

Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

Any additional context: I can work around this by making an API call to edit the disabledFeature list but this is not ideal in a production environment.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[mattkime]

This is working as intended. We could certainly debate whether this is the best behavior but we can't really change it because existing users rely on it.

Is there a reason why you're disabling the feature for a space as a whole instead of using role based kibana privileges?

[DBolge]

A customer is disabling a raft of features for all spaces, this included. I'm missing something though, if that is a security boundary why does it apply to a superuser? Surely that makes no sense as I can literally enable the feature and do what I need to do then disable it again.

[jeramysoucy]

if that is a security boundary why does it apply to a superuser? Surely that makes no sense as I can literally enable the feature and do what I need to do then disable it again.

Disabling a feature within a space applies a restriction within the space. It will affect all users within the space, including superusers (amended: though it should not affect API access). As @mattkime suggested, if the Data View feature is needed in the Space it should not be disabled in the space, and instead, the customer can use role-based kibana privileges to control access to Data View management. https://www.elastic.co/guide/en/kibana/current/xpack-spaces.html#spaces-control-user-access

[mattkime]

Thank you @jeramysoucy - that's the best we have to offer right now.

I've created this issue to track the resolution of this problem - https://github.com/elastic/kibana/issues/188569