Detect and fail early if user attempts to upgrade Agent using the CLI in unsupported scenarios

[kaanyalti]

• Relates Don't fail checkin if agent has upgrade details with no action fleet-server#3991

Version: 8.14.0
Operating System: Ubuntu 24.04 LTS
Platform: arm64

While working on this issue comparing root and unprivileged elastic agents, I encountered an error when upgrading the agent.

Steps to Reproduce:

1. Deploy ESS v8.14.0
2. Create agent policy with system integration
3. Install fleet managed agent v8.13.4 with or without the unprivileged flag sudo ./elastic-agent install --url=<fleet url> --enrollment-token=<token>
4. Run sudo elastic-agent upgrade 8.14.0
5. Upgrade seems to work; however, when checking the status we get the following error

┌─ fleet
│  └─ status: (FAILED) status code: 500, fleet-server returned an error: BadRequest, message: failed to update upgrade_details: upgrade_details no action for id "" found
├─ elastic-agent
│  └─ status: (HEALTHY) Running
└─ upgrade_details
   ├─ target_version: 8.14.0
   ├─ state: UPG_WATCHING
   └─ metadata

6. Uninstall and unenroll the agent and install v8.13.4 again
7. Upgrade through the fleet ui. This should work.

This bug occurs for both privileged and unprivileged agents.

Definition of Done

Synthesized from #4890 (comment):

• If an unprivileged user attempts to upgrade a Fleet-managed unprivileged Agent from the CLI, Agent should refuse to upgrade and output a message explaining why and additionally mention that the upgrade cannot be performed because the command was not executed with root/Administrator permissions (same as the isAdmin check in cmd/install.go).
• If a privileged user attempts to upgrade a Fleet-managed Agent (privileged or unprivileged) from the CLI (elastic-agent upgrade ...), Agent should refuse to upgrade and output a message explaining why. The message should NOT mention anything about a --force flag (explained below).
• However, if a user additionally provides a --force flag in the previous scenario, Agent should present a warning message and proceed with the upgrade anyway. This --force flag should be hidden; it should NOT show up in the output of elastic-agent help upgrade.

[kaanyalti]

cc: @ycombinator @cmacknz

[cmacknz]

Upgrading Fleet managed agents from the cli isn't supported. We should detect this and fail earlier before attempting the upgrade.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[ycombinator]

Upgrading Fleet managed agents from the cli isn't supported. We should detect this and fail earlier before attempting the upgrade.

++ renamed issue title accordingly.

[vx-sec]

What's the reason for not supporting CLI upgrades? I have agents that can't reach the web but are reachable by SSH, so I can push the package to them and upgrade through Ansible, which works quite well. Setting up an artifact repo is also not an option, as I don't control what those agents have access to.

EDIT: or at least Kibana should allow file:// URLs when adding a new agent binary download source

[cmacknz]

This is only for Fleet managed agents, who expect to be told to upgrade from the Fleet UI and not the CLI today.

The specific error in the issue is that the agent reports its progress through the upgrade back to Fleet and if the upgrade wasn't started from the UI Fleet considers it an error since the upgrade is unexpected.

I think there are some situations where initiating upgrades of Fleet managed agents from the CLI is useful, but we'd have to fix this error for this to work properly.

Also with unprivileged agents where users who are not root/admin can potentially use the CLI, forbidding upgrades from the CLI is a way to prevent upgrades outside of Fleet's control from occurring which is probably desirable to many people. We'd have to consider this too if we change approaches here.

[cmacknz]

elastic/fleet-server#3991 will remove the 500 error when this happens.

I am a little bit hesitant to just forbid running elastic-agent upgrade at all when Fleet managed, the Fleet managed upgrade process involves a lot of machinery and being able to upgrade from the CLI is a useful escape hatch if things go terrible wrong.

We could add a log that it's unsupported with a confirmation to proceed anyway to clarify expectations though.