Refactor: Use the capabilities to defined if an Agent is upgradable or not about elastic-agent HOT 4 OPEN

I think we should scope the action based on the input type and for elastic-agent use that for its type, so requiring all actions to have a prefix of {input-type}/{action-name}. So for the Elastic Agent it would look like?

capabilities:
- rule: deny
  action: elastic-agent/upgrade

That would allow actions targeting specific inputs to also be denied. Thoughts?

from elastic-agent.

Pinging @elastic/agent (Team:Agent)

from elastic-agent.

++ on adding it to capabilities.

@ph Can you elaborate on the action approach? You mean it would cover multiple cases at once directly? If yes, kind of like the idea.

We will need to make sure independent of the implementation, that an Agent reports its capabilities so Fleet can disable certain UI components / API calls.

from elastic-agent.

@ruflin Yeah, This is my point, we could cover multiple cases with a single strategy. Every command send from Fleet is an action, including upgrade so if we add something to control which kind of action we can executed on the agent we actually support the current use case of an upgrade and any potential action we would like to restrict in the future.

And by doing so we only need to figure out "how capabilities" are surfaced back in the UI.

from elastic-agent.