Add a way to unenroll an Elastic Agent from the client side

[jamiesmith]

Describe the enhancement:

Currently there's no way to unenroll an elastic-agent from the client side

Describe a specific use case for the enhancement or feature:

When running ephemeral instances (containers, for example) each can enroll, but when the container is stopped we end up with stranded offline instances in fleet, which then takes two commands per host on the Fleet screen (unenroll and force unenroll, because they never unenroll), for a total of 6 clicks, plus delays, for each host.

If there were an unenroll subcommand for ./elastic-agent it could be called in the container teardown

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[EricDavisX]

we should be able to mitigate some of this with plans in place already for 'bulk actions' coming soon; wherein you can select all of the stranded agents, and then do the clicks just once a day or once a week (etc) to get rid of cruft in the UI. I like the idea of having more support on the Agent side, I'm not sure if there are technical reasons it wasn't implemented or considered prior - but we can evaluate it and put it to the roadmap, etc. thanks for logging!

[ph]

@ruflin Can you look into this, I think its related to the higher discussion concerning how we work with container.

[ruflin]

I like the idea of having an elastic-agent unenroll command. This could also be useful if a user wants to switch from managed to standalone. @blakerouse WDYT?

@jamiesmith Is there an option in docker to have a special call on teardown? If not, an option could also be that an Agent is started with a flag -ephemeral which means when the agent is stopped, it also unenrolls.

[jamiesmith]

I am running it with a shell script in the container, so I would just set up an exit trap, which I verified works (except for a force stop).

[jamiesmith]

Oh, the ephemeral option is good too

[blakerouse]

@ruflin I think elastic-agent unenroll is a good idea. I do wonder if there is a use-case where a user cannot call elastic-agent unenroll based on setting from Fleet.

[ph]

@blakerouse @ruflin

Good point, lets say you have laptop It would be weird to allow someone to unenroll.
Could it be something we configure on the Agent Policy like this Policy only allow for ephemeral agent?

[ruflin]

I'm not sure the permission to unenroll is always tied to ephemeral feature but we could start with that and then iterate if we get other requests. Also not convinced if a single policy only serves ephemeral agents. Why not an additional flag/setting to make it more obvious?

On top of setting it in the policy, it could also be part of capabilities elastic/beats#21096 A user could probably work around it by stopping and agent, change capabilities and restart it. But that is something the system at least would see.

[ph]

@blakerouse Can you take a look at this? A bit related to the k8s story.

[blakerouse]

Will look into it, think it is related to uninstall. Both could probably be solved at once.

[elasticmachine]

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

[jlind23]

Closing for now as it never was prioritized. Can be reopened later on if needed. cc @nimarezainia

[ulab]

I am a little flabbergasted, why an uninstall does not include an unenroll. There should at least be both options available.

[nimarezainia]

@ulab we would prefer to rely on our state machine to unenrol the agent from Fleet when the un-installation at the remote host has occurred. When uninstalled, the agent will miss checkins and transition to OFFLINE and INACTIVE and eventually removed. these changes have been implemented i the upcoming release.