Elastic Agent Docker: agent always picks up the newest policy

[mtojek]

Hi,

I'm working on the Kubernetes integration and just spotted a weird issue. Steps to reproduce:

1. Create a policy A.
2. Run new Docker container with Elastic Agent. The agent will get enrolled and will be assigned the newest available policy (policy A, not Default).

If I'm working on a policy which is not ready yet and suddenly a new agent boots up, it should pick up the Default policy.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[mtojek]

I have also found that Elastic Agent is trying to use non-active enrollment token by default.

[ph]

@mtojek Are you using the token associated with the Default policy?

[mtojek]

No, I'm not passing any enrollment key and I expect from the Dockerized app to pick up the default one.

[ph]

I've talked with @mtojek on slack, and the logic defined in our shell script lead to inconsistent behavior.

The pseudo logic should be something like this.

• Get the list of agent policies.
• Get id of the Default Agent policy
• If the Default Agent policy is not found raise an error and suggest using the API key instead.

@mtojek WDYT ^?

[mtojek]

Yes, this would be the ideal flow.

[nchaulet]

There is for sure a bug in the docker script but I am wondering if it’s the docker image we publicly distribute if yes, I think we should really avoid the user to provide the Kibana username and password and we should probably only allow to provide the enrollment token.

[mtojek]

One more point about tooling. We use auto-enrollment feature in elastic-package to test integrations, so it would be backward-incompatible to enforce providing the enrollment token.
Please keep in mind that it's a convenient option to quickly boot up the Agent in Docker or Kubernetes cluster using static resources: https://github.com/elastic/beats/blob/master/deploy/kubernetes/elastic-agent-kubernetes.yaml /cc @ycombinator @ruflin (let's collect some comments here)

[ycombinator]

++ to pseudo-logic suggested by @ph in #23928 (comment). It will lead to deterministic behavior, which is a good thing.

[mtojek]

@ph @nchaulet could you please provide ETA on this issue? I'd like to know whether I should introduce a workaround for this bug in elastic/elastic-package#246 . I'm fine with keeping the discussion whether the option is good or not, but it would be convenient to detach it from fixing for the reported issue.

[elasticmachine]

Pinging @elastic/agent (Team:Agent)

[ph]

@mtojek I agree that fixing the behavior and doing the right think are separate discussion. @mtojek I think implementing the workaround and fixing the issue would take a similar amount of time, can you make a PR?

[ph]

I think we can close this will the recent changes for the Elastic Agent and Fleet server?