Possible to assign Kibana feature privileges independent of Space?

Elastic Stack Kibana
1

Elasticsearch and Kibana 8.17
Platinum license

Is it possible to assign Kibana feature privileges independent of Spaces? Or do I need to redesign my access?
For example, if I have a Developer Role, the features they'd use are the same regardless of what Space they're in, but I don't want every Developer to have access to every Space. Space access is ideally controlled by a separate role.

The privilege and access setup I'm going for is:
Privilege and Feature Access Roles

  • Read role - base access role. Allows user read access to Discover, Dashboard, and Visualizations. Does NOT grant any specific index or Space access.
  • Reporting Role - adds another layer of permissions on top of Read role, such as ability to export from Discover, Dashboard, Viz, and save searches.
  • Developer Role - adds yet another layer of permissions on top of Read and Reporting roles, allows user to create and update Data Views, manage Saved Objects

Project and Space Access Roles

  • Project_A_Access Role - grants access to the project's Space, Project_A, and index pattern, proj-a_*
  • ...
  • Project_M_Access Role - grants access to the project's Space, Project_M, and index pattern, proj-m_*

Since Kibana uses a union of privileges, this would ideally mean that I could have:

  • User01 - assigned Read, Project_A_Access. Gets read-only access to Project_A Space, can only view proj-a_* index pattern, and read only for Discover, Dashboards, Viz, within the Project_A Space only.
  • User02 - assigned Read, Reporting, Developer, Project_A_Access, Project_M_Access. Gets access to both Project_A and Project_M Spaces, and index patterns proj-a_* and proj-m_*. Within only those 2 Spaces, addition to creating and updating Discover, Dashboards, Viz, can also manage Saved Objects and Data Views).

Currently, it doesn't seem possible set this up. If I make, for example, a Reporting role with access to all Spaces, then that user can view all Spaces, and has those features on all Spaces, even if their index access is managed by another role. This allows 2 things I need to avoid: the user can view other all projects/Spaces that exist, including dark projects, or vendor-specific projects; and the user has the ability to create objects from one index in another Space, for example, they could create a Dashboard sourcing proj-a_* in the Project_M Space.
If instead of setting it to all Spaces I just give it the Default space with the desired Kibana feature privileges, and manage Space access with another role, like Project_M_Access, it won't give the user any Kibana feature privileges not specifically assigned to that Space. ie, it doesn't do a union of Reporting's access to the feature privileges set under Default, with Project_M_Access's access to the Project_M Space.

So at the moment, I'm stuck making a ton of roles for each project/Space, basically:
projectName_accessRole, like Project_A_Read-Only, Project_A_Reporting, Project_A_Developer, ..., Project_M_Read-Only, and so on. As you can see, this quickly gets out of hand with a lot of projects.

Maybe, am I thinking about Spaces or my whole access design wrong?
Right now, Projects are tied to Spaces. Each Project needs to be isolated, ie, no user should have any visibility to any other projects unless they are explicitly assigned to those projects via Roles. So they shouldn't see other Spaces, Dashboards, Panels, etc. Even if they don't have access to the underlying index for any visualizations, the object's name alone can give information about a project or its existence.
Is there another way to maintain this strict separation, while keeping Roles easy to manage?

2

Update:
I haven't found a solution to this, but did come up with something at least workable for our team's use case. We're migrating access management to use SSO, so users are managed via groups from the IDP. I made access groups (Project A, Project M, etc), and permissions groups (Developers, Reporters, etc) on the IDP. On Kibana, I still had to have project_role roles, and a role mapping for each of those roles. Role mapping uses AND to assign roles, so someone in the Developer group and also in the Project A group gets the Project_A_Developer role.
The caveat with this, aside from still having a ton of roles to manage on the Kibana end of things is that users can't be given different access levels to different projects. In our use case, though, we don't have any cases where someone would be a developer for one project, but only a reporter or read-only for another. So this works for us, for now, but YMMV.

I'd still prefer to see the ability to set Kibana feature privileges and access to Spaces separately.