[Fleet] Agent privilege level change UI

[jillguyonnet]

Summary

Closes #221891
Closes #221892

This PR implements the UI for the new agent privilege level change API (single agent and bulk).

Key changes:

• Add an agent version check: this had been missed in the API implementation; agents should be on 9.3.0 or higher, otherwise attempting to remove root privilege through the API will fail and the UI will not allow it.
• Add a check if the agent is already unprivileged:
  • POST /api/fleet/agent/{agent_id}/privilege_level_change: return 200 with message "Agent {agentId} is already unprivileged", no action created
  • POST /api/fleet/agents/bulk_privilege_level_change: no change (confirmation pending)
  • UI: don't show the option for root privilege removal
• Add is_action_secrets_storage_enabled to Fleet setup API (GET kbn:api/fleet/agents/setup).
• Add "Remove root privilege" action for Fleet agents in Fleet UI (cf. screenshots).
• Store optional user password as secret if action secrets storage is enabled (all Fleet servers on 9.3.0 or higher).

Screenshots

Click to reveal

⚠️ At the time of writing, Elastic Agent 9.3.0 is not available yet, so screenshots show 9.2.0 instead.

Considering 4 agents:

• Agent on version 9.3.0 on agent policy with an integration (System) that requires root privilege: root privilege removal denied.
• Agent on version 9.3.0 on agent policy with no integrations: root privilege removal permitted.
• Agent on version 9.1.0 on agent policy with no integrations: root privilege removal unsupported.
• Agent on version 9.3.0 already unprivileged: root privilege removal permitted but not offered in the UI.

The single agent actions in the table rows only show "Remove root privilege" if the agent is eligible:

Clicking on "Remove root privilege" opens a flyout for the agent, allowing the user to specify options (here, action secrets are enabled and the password field would be stored as a secret if specified):

If action secrets are not enabled, the user password is stored as plain text:

If the action is successfully created, a notification is shown:

The bulk agent actions show "Remove root privilege for N agents" when agents are selected:

In this case, the flyout will report which agents are not eligible if any and only create the action for eligible agents:

The agent details page also offers the action (as well as migration):

With the flyout:

Checklist

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• Flaky Test Runner was used on any tests changed
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines
• Review the backport guidelines and apply applicable backport:* labels.

Identify risks

These changes only impact the new Fleet agent privilege level change API.

Release note

Adds a functionality for removing root privilege from Fleet managed agents if applicable.

[jillguyonnet]

@sileschristian Could I please get a UX review from you? Notably the following questions:

1. Flyout texts ("root privilege" instead of "root access"?).

2. Action icon: I thought the wrench could make sense, but not sure 😄

3. Should we reorder the agent actions in the single agent action and bulk actions menus? There seem to be discrepancies between the two, and maybe it would make sense to review the order from a UX point of view (e.g. perhaps less common actions should be lower in the menu?).

Screenshots:

Click to reveal

Single agent action:

Bulk actions menu:

[jillguyonnet]

A note: currently neither the API or the UI reject handling an agent that is already unprivileged. @michalpristas let me know if it should be the case.

[michalpristas]

i'm up for fast result, now the question is should it fail or succeed.
my guess would be failure but i'd like more input from @cmacknz or @kpollich

[jillguyonnet]

i'm up for fast result, now the question is should it fail or succeed.
my guess would be failure but i'd like more input from @cmacknz or @kpollich

Fleet rejects fast if the agent is on an unsupported (< 9.3.0) version or if needs root privilege (e.g. it's on an agent policy with the system integration). We could certainly return fast if it's already unprivileged. In this case, it would probably also make sense to hide the option in the UI, same as unsupported version and requires root privilege. Also, even though the endpoint is named privilege_level_change, it is really root privilege removal, so it seems like it would make sense to reject the request.

[cmacknz]

Fleet rejects fast if the agent is on an unsupported (< 9.3.0) version or if needs root privilege (e.g. it's on an agent policy with the system integration). We could certainly return fast if it's already unprivileged. In this case, it would probably also make sense to hide the option in the UI, same as unsupported version and requires root privilege. Also, even though the endpoint is named privilege_level_change, it is really root privilege removal, so it seems like it would make sense to reject the request.

Attempting to change the privilege level from unprivileged to privileged should return an error quickly, something equivalent to an HTTP 501 Not Implemented.

A request to maintain the privilege level of an unprivileged agent should succeed quickly, equivalent to a 200 OK. This would let users retry bulk privilege level changes where only some of the agents have succeeded in the batch.

[cmacknz]

A request to maintain the privilege level of an unprivileged agent should succeed quickly, equivalent to a 200 OK. This would let users retry bulk privilege level changes where only some of the agents have succeeded in the batch.

In the UI for an individual agent that is already unprivileged we shouldn't show the privilege level change / remove root access as an option if we aren't already doing that.

[jillguyonnet]

Thanks for your input @cmacknz

Attempting to change the privilege level from unprivileged to privileged should return an error quickly, something equivalent to an HTTP 501 Not Implemented.

It's not even possible in the current implementation. Calling POST /api/fleet/agent/{agent_id}/privilege_level_change or /api/fleet/agents/bulk_privilege_level_change attempts to lower the level to unprivileged: the unprivileged flag is hardcoded to true here (single agent) and here (bulk).

A request to maintain the privilege level of an unprivileged agent should succeed quickly, equivalent to a 200 OK. This would let users retry bulk privilege level changes where only some of the agents have succeeded in the batch.

Great point 👍 I added fast success for single agent. For bulk, I ran into a slight complication: currently, for a Fleet-created action, we expect action.nbAgentsActioned === action.nbAgentsActionCreated + action.nbAgentsFailed. If we want fast success for unprivileged agents (essentially, skip them but don't create an error), it seems to me that a proper solution would be to add an action field like nbAgentsSkipped (such that action.nbAgentsActioned === action.nbAgentsActionCreated + action.nbAgentsFailed + action.nbAgentsSkipped). It seems like a significant change to add, so I would like feedback from @juliaElastic and @criamico on this point. Currently, unprivileged agents are included.

In the UI for an individual agent that is already unprivileged we shouldn't show the privilege level change / remove root access as an option if we aren't already doing that.

Added 👍

[jillguyonnet]

@sileschristian Thanks for your feedback!

I pushed the following changes to this PR:

• icon changed from wrench to lock
• "root access" replaced with "root privilege"

I opened #238091 for followup changes. Since we have that issue to discuss the redesign of these menus, I would rather keep the changes in this PR related to privilege level change only.

I've also updated the screenshots in the PR description. Please let me know of any further feedback 🙏

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[juliaElastic]

Great point 👍 I added fast success for single agent. For bulk, I ran into a slight complication: currently, for a Fleet-created action, we expect action.nbAgentsActioned === action.nbAgentsActionCreated + action.nbAgentsFailed. If we want fast success for unprivileged agents (essentially, skip them but don't create an error), it seems to me that a proper solution would be to add an action field like nbAgentsSkipped (such that action.nbAgentsActioned === action.nbAgentsActionCreated + action.nbAgentsFailed + action.nbAgentsSkipped). It seems like a significant change to add, so I would like feedback from @juliaElastic and @criamico on this point. Currently, unprivileged agents are included.

With the current logic we can already retry the bulk action and have it partially succeed for those agents that are not unprivileged. Isn't that the goal?

[florent-leborgne]

LGTM, just a few super minor copy styling suggestions

[vishaangelova]

Thanks! Left a couple of suggestions for your consideration:)

[juliaElastic]

Maybe we could drop these agents before they get processed to create the action, i.e. filter them out of this list. The result would be that they silently get filtered out though, which is not ideal.

Yeah this would result in inconsistencies on the UI e.g. actioning 50 agents and then seeing 48 being actioned.

Alternatively, we keep the current solution (process them) with the option to improve this in the future (as you said, reworking the bulk action framework should be its own issue). The UI will already prevent attempting processing already unprivileged agents for manual selection, so the only scenarios where we could try to do it would be through the bulk API (either list of ids or kuery) and select all (kuery) in the UI. It seems to me like an acceptable first solution. WDYT?

Sounds good to me.

[jillguyonnet]

@juliaElastic FYI I captured the discussion around potentially modifying bulk actions in #238220

[juliaElastic]

Should we add the action to the agent details page too? I think we missed to add the migrate action too.

[jillguyonnet]

Should we add the action to the agent details page too? I think we missed to add the migrate action too.

Good point! I'll add that, and also a mention of this menu in #238091.

[cmacknz]

Alternatively, we keep the current solution (process them) with the option to improve this in the future (as you said, reworking the bulk action framework should be its own issue). The UI will already prevent attempting processing already unprivileged agents for manual selection, so the only scenarios where we could try to do it would be through the bulk API (either list of ids or kuery) and select all (kuery) in the UI. It seems to me like an acceptable first solution. WDYT?

Agreed if there is significant work here it doesn't need to be tackled in this PR. Increasingly we need to be thinking of handling actions like this the same way we do for automatic upgrades. Users are declaring a target state for the agent (be a specific version, have a specific privilege level) and Fleet needs to automatically converge the agents to the state without users needing to button click through one off failures or agents that happen to be offline during the initial conversion.

[jillguyonnet]

@elasticmachine merge upstream

[jillguyonnet]

@elasticmachine merge upstream

[vishaangelova]

UI copy LGTM 🚀

[juliaElastic]

LGTM