Make Fleet spaces aware

[zez3]

There was this discussion here:
https://discuss.elastic.co/t/elastic-agent-fleet/254691

Also my other issue elastic/kibana#132559 that I suppose it can be moved or closed as long as this one will get a team assigned

and an Internal ER number 17456

[nicpenning]

Great post here, the RBAC for Fleet is greatly needed!

There is typically a great divide between Server admins and Endpoint Admins so each should be able to maintain and manage their own without the other interfering. It will be much more practical then creating separate clusters to handle this type of requirement.

[nicpenning]

Should a new issue be created for Role Based Access Control for Fleet? Or this one renamed to better align with the actual need here for logically separating access to Fleet components (integrations, policies, agents, etc..).

[jlind23]

@nicpenning I don't think a new issue is needed as it will greatly overlap with the intent of this one.

[nicpenning]

Looking for an update here on RBAC for Fleet. Is this in the works? Being tracked elsewhere?

[zez3]

@jamiehynds
Any updates on this?

[zez3]

@nimarezainia

My sysadmin colleagues are asking for this feature more, than ever. They want to control the updates of the Agents themself.
I don't want to create a workaround that will be obsolete soon. I just need to know that it's happening and get an idea of about when.

[nimarezainia]

@nimarezainia

My sysadmin colleagues are asking for this feature more, than ever. They want to control the updates of the Agents themself. I don't want to create a workaround that will be obsolete soon. I just need to know that it's happening and get an idea of about when.

@zez3 and @nicpenning we are working on making Fleet space aware, this is one of the higher priority features under consideration at the moment.
So that roles within one space don't have access to another (eg. one space won't be able to read or make changes to agent policies (and by extension agents) that belong to a different space, they won't be able to see other spaces' enrollment tokens, they will only be able to perform Fleet actions such as upgrades to agents/policies in their own space etc). We won't be considering space awareness for ingest pipelines or datastreams with these changes.

A question for you on this topic: I'm somewhat familiar with each of your environments. If fleet was made to be space aware, how should we treat the Fleet-->Settings tab in your opinion? changes here are global and would affect all the users on the platform. Would you consider an admin (super user role type) to be the persona that has read/write access to these global settings tab and the only role that could add outputs, modify fleet-server settings and add proxies? Other roles (in the context of their own space) could then modify their agent policy to use global settings such as a new output created.

[nicpenning]

I can see where Fleet Settings would simply be disabled/hidden for users that don't have the super user or appropriate user access to perform fleet setting changes.

Also, I think it's okay that ingest pipelines and data streams need not be space aware, I can't think of any use case where that would be needed.

The biggest thing right now is server admins managing server agents vs endpoint admins managing endpoint agents and SOC managing all, some or none of those and other key agents. Doing this via spaces seems logical as they would have their own view of what can be managed.

[zez3]

A question for you on this topic: I'm somewhat familiar with each of your environments. If fleet was made to be space aware, how should we treat the Fleet-->Settings tab in your opinion? changes here are global and would affect all the users on the platform. Would you consider an admin (super user role type) to be the persona that has read/write access to these global settings tab and the only role that could add outputs, modify fleet-server settings and add proxies? Other roles (in the context of their own space) could then modify their agent policy to use global settings such as a new output created.

@nimarezainia
That sounds about right. The Fleet Settings should be gray-out if they have read-only or simply not allowed to be visible if they don't have any permissions.
As Nic mentioned our colleagues the SysAdmins have the need to self manage the Agents and the policies. We(Security Team) we need to manage/(OS)query more or all. I usually do this from the Default Space.
Especially related to the latest metricbeat memory leak elastic/beats#37142 that affected and annoyed a few of my windows admin colleagues. They requested to be able to self tune the policies and control the Agent.

[jlind23]

Closing this in favour of the issues below which are all space awareness related.

• [Fleet] Create proof of concept space migration for Fleet saved objects kibana#180708
• [Fleet] Migrate Fleet's saved objects from namespaceType: agnostic to namespaceType: single kibana#181860
• [Fleet] Add space ID to Fleet system indices kibana#182717
• [Fleet] Support spaces in fleet object created by Fleet Server #3505
• [Fleet] Make preconfiguration space-aware kibana#182817
• [Fleet] Fleet should allow an integration to be installed/reinstalled into another space kibana#172963
• [Fleet] Ensure integrations can be installed across many spaces within new space awareness model kibana#182735
• [Fleet] Include space ID in namespace piece of integration data stream names kibana#182729
• [Fleet] Create UI for assisting with moving Agent Policies between spaces kibana#182733
• [Fleet] Test first-time onboarding flows in new space awareness model kibana#182736