[Fleet] Notify the user if the integration being deployed needs root privileges

[nimarezainia]

Elastic Agent is removing the requirement to run in a privileged mode. The package-spec has been modified to indicate whether the package as a whole or a datastream within the package requires root privilege.

Feature Request:

• Warn the user if they are installing an integration that requires super user privilege.

Definition of done:

• Every time an integration that requires root privileges is installed, users should see a yellow disclaimer in the UI.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[strawgate]

Will there be an indication in the agent diagnostics / fleet / will an agent be considered unhealthy if it does not run as root but there is an integration in the policy that requires running as root? Is that outlined somewhere?

[nimarezainia]

Will there be an indication in the agent diagnostics / fleet / will an agent be considered unhealthy if it does not run as root but there is an integration in the policy that requires running as root? Is that outlined somewhere?

The meta issue https://github.com/elastic/ingest-dev/issues/1766 has a requirement for health reporting to be enhanced for this purpose

[joshdover]

Warn the user if they are installing an integration that requires super user privilege.

Product questions:

• Should we always warn the user or only if there are agents on the policy installed as non-root?
• If we are detecting agents installed as non-root, should the warning include a count of agents that are non-root or a link to view which ones?
• Do we agree we only do this when the user creates an integration policy, not if they install just the backend assets of the package?
• What should happen if the user later tries to enroll an agent in a policy that already has an integration that requires root? Just a warning via health reporting?

Technical questions:

• If we need to query for agents installed as non-root, how will that be reported to Fleet? Is it during enrollment time or as part of check-in?
• How will we handle agents that were enrolled before this change was implemented or on older versions of Agent that don't report this property?
• How do we handle agents running in containers? How do we determine "rootness" if they have some seccomp privileges but not others?
  • This is probably more of a question for @blakerouse

[jlind23]

@joshdover @amitkanfer following our conversation today I changed the outcome of this issue to:

• Every time an integration that requires root privileges is installed, users should see a yellow disclaimer in the UI.

@nimarezainia @zombieFox what do you think about adding a new disclaimer on this page saying that root privileges are needed?

[jlind23]

Copying @jen-huang comment from Slack:
@zombieFox do you have some time to do a quick mockup for this? #166784
@jlind23 suggested putting on the Settings page, but I don’t think that is very visible (first time adding an integration will not go through this page, for example). somewhere in the page header or overview page may be a better option

[joshdover]

@nimarezainia @zombieFox what do you think about adding a new disclaimer on this page saying that root privileges are needed?

Most users don't install the integration this way and actually installing this way doesn't require root privileges. It probably needs to be on the policy creation flow.

[zombieFox]

Giving this some thought. I like the idea of placing this information on the Overview page along with other install information. I know the content of the Overview page is pulled from the readme files -- so thoughts on adding a new section to the right column?

[nchaulet]

@joshdover @jlind23 it is the overview solution the only thing we want here? do we also want something in the package policy editor that is another place to install an integration?

[nimarezainia]

@joshdover @jlind23 it is the overview solution the only thing we want here? do we also want something in the package policy editor that is another place to install an integration?

@nchaulet where ever the user would be installing an integration. So in short yes, policy editor as well.

[joshdover]

Can we be sure we don't call this "super user" anywhere in the final UI or docs? It's not a common term from my understanding and it also overlaps with our Elasticsearch role called superuser. It should probably be something like root privileges (linux and mac term) or adminstrator privileges (windows term)

[joshdover]

where ever the user would be installing an integration. So in short yes, policy editor as well.

@nimarezainia we need to specify what this would look like. Would it make sense to put it near the top under the integration settings?

[nchaulet]

@jsoriano I am working on the kibana implementation and it seems the agent.privileges.root: true are not published through the package registry, if we want to display this in the integration details page we probably need it (as we rely on the registry GET /packages/{name}/version and are not fetching the whole archive here), do you see any reason to not add it?

Draft here elastic/package-registry#1109

[nchaulet]

@nimarezainia @zombieFox I tried to put it in different place in the package policy page let met now if there is one that will work for you (and if you have better copy idea to)

1. as josh suggest in the step 1

2. on top of the package policy editor

3. when selecting agent host (I think it could make sense to make it here as it's the link between the package policy and the agents)

[nimarezainia]

@nchaulet I would say that option 2) would be the best option - just my opinion. I think best not to have this buried in with the rest of the settings and have it at the top before the user goes any further - almost as a warning. (I do like option 3 as it's part of the editor related to the actual host but that also is way too late)

[ferullo]

Sorry to chime in so late, I'm not sure where else to ask this. If a non-root Agent has a policy applied that includes integrations that require root what does that failure look like in Fleet for the Agent? Will it be readily evident to the user why their Agent is unhealthy?

[jlind23]

Then the input will fail and the agent will report itself as unhealthy. As of today fleet does not know if the agent is run as root or not.