Prevent users from upgrading standalone agents in container, deb, and rpm environments

[ycombinator]

Describe the enhancement:

Standalone Elastic Agents that are running in a container or deployed via DEB or RPM packages should not be upgradable using the elastic-agent upgrade ... CLI command.

Describe a specific use case for the enhancement or feature:

What is the definition of done?
Running elastic-agent upgrade for standalone Elastic Agents should fail with a descriptive message when Elastic Agent is deployed:

• in a container
• via a DEB package
• via an RPM package

[elasticmachine]

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

[cmacknz]

We already have detection for most (all?) of these cases:

elastic-agent/internal/pkg/agent/application/upgrade/upgrade.go

Lines 69 to 74 in 49579ae

	// IsUpgradeable when agent is installed and running as a service or flag was provided.
	func IsUpgradeable() bool {
	// only upgradeable if running from Agent installer and running under the
	// control of the system supervisor (or built specifically with upgrading enabled)
	return release.Upgradeable() || (paths.RunningInstalled() && info.RunningUnderSupervisor())
	}

When we do this, we should consider including a --force flag or similar as an escape hatch in case this logic ever has a bug. We report the upgradable state to Fleet and it is used to block upgrades from the UI, but there is an underlying API with a similar force flag in Fleet.

[pchila]

I was more thinking about introducing a placeholder/marker file like upgrades.disabled file in the agent main directory and only add it to the packages where the update is off by default. This should be pretty simple to implement

[cmacknz]

I like it, much more reliable. We should replace the existing upgradeable check with that.

[swiatekm]

I agree with Paolo as well. Whether the agent is upgradable this way is really a property of the package, and so should be part of it in some way. A marker file is straightforward enough, and can only be wrong due to packaging bugs.

[michalpristas]

maybe we should make it more generic and future proof and handle it in a similiar fashion as beat modules
https://github.com/elastic/beats/blob/main/libbeat/cfgfile/glob_manager.go#L50
i wonder if glob manager could be reused and brought to agent repo

usage: https://github.com/elastic/beats/blob/83ce2f7ceada4d572795cdc558762a98999cae12/metricbeat/mb/module/configuration.go#L52

[kaanyalti]

I have some questions to clarify what needs to be done.

• The issue specifically mentions standalone agents. I was under the impression that agents running in a container, or installed by a package manager are not upgradeable regardless of whether they are standalone or fleet managed. Is this correct?
• Is this implementation supposed to be restricted to the cli?

[michalpristas]

enrolled or not should not matter

[pierrehilbert]

I tend to agree with @michalpristas, the main goal is to highlight the reason why we can't upgrade the Agent through the CLI (the way it has been installed first).

[cmacknz]

Fleet enrolled agents on these platforms should already be prevented from upgrading in the Fleet UI via the upgrade action. The agents should be marked as non-upgradable. If this isn't the case we need to fix it.

+1 that the elastic-agent upgrade command shouldn't special case Fleet enrolled agents. You cannot use the agents own upgrade process on any of these package types, it will not work. The container filesystem is immutable, the DEB and RPM package structures are different and agent's upgrade process isn't aware of that.

[kaanyalti]

I should clarify my question here. The issue specifies that this update restriction should be implemented for the cli; however, cli being only one of the entry points to the agent I wasn't sure if there is an upgradability check implemented for the fleet-server entry point. If we need this restriction implemented for both entrypoints, then implementing it in the application layer may make more sense. I am probably missing some details, so please correct me if I'm wrong.