Ensure fleet deployment uses fleet url provided by fleet_server_host_id

[MichelLosier]

Summary

Resolves: #221900

In an ECH environment, if a user creates a new fleet server and sets it as default, a new agentless deployment can be created that uses the url of the new default fleet server, but the enrollment API key of the expected preconfigured fleet server. For agentless deployments, we'll want to use the default managed fleet server provided in the cloud environment

To reproduce (on main):

Ensure the kibana.dev.yml is setup to enable agentless, and to think its in a cloud environment, specifically ECH

xpack.cloud.id: 'anything-here-is-valid'
xpack.fleet.agentless.enabled: true
xpack.fleet.agentless.api.url: 'http://localhost:3000'
xpack.fleet.agentless.api.tls.certificate: './config/certs/ess-client.crt'
xpack.fleet.agentless.api.tls.key: './config/certs/ess-client.key'
xpack.fleet.agentless.api.tls.ca: './config/certs/ca.crt'

Make sure the default fleet server host id and output ids match what is expected for ECH:

xpack.fleet.fleetServerHosts:
  - id: fleet-default-fleet-server-host
    name: Default Fleet server
    is_default: true
    host_urls: ['https://your-local-ip:8220']

xpack.fleet.outputs:
  - id: fleet-default-output
    name: Default output
    type: elasticsearch
    is_default: true
    is_default_monitoring: true
    hosts: ['http://your-local-ip:9200']

Steps:

• Add a new fleet server in the UI, and set is as default. Use a host url that you can easily distinguish from the preconfigured default fleet server
• Add the Okta integration as agentless
• Observe the log line from Kibana fleet api server [Agentless API] Creating agentless agent with fleetUrl ${fleetUrl} and fleet_token: [REDACTED] show the fleetUrl for the new default fleet server.

Then try the same steps on this branch and observe the same log line. You should see the fleetUrl match the preconfigured one.

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
• Flaky Test Runner was used on any tests changed
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines
• Review the backport guidelines and apply applicable backport:* labels.

Identify risks

Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss.

Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging.

• See some risk examples
• ...

[MichelLosier]

This draft PR at this point is to more so demo the issue and a "for now" path we could take, but @jen-huang given the underlying issue for this, it seems that maybe the more durable solution, and what I lean towards, would be to have agentPolicyService.create for agentless policies always use the ID constants for the default output and fleet server host for the cloud environments by extracting and reusing this bit of logic here:

• https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/fleet/server/services/agentless_settings_ids.ts#L30-L42

When I was working in this area I came across the code comment linking to:

• https://github.com/elastic/ingest-dev/issues/5924

which led me to the draft that you put up recently related to that here:

• [UII] Use explicit fleet server & output IDs for agentless on ECH and Serverless #225188

If I take the path I'm proposing (using constants and not relying in req params for agentless), I don't want to create too much merge conflict for what you are setting up there. That said, I could just branch off your draft instead and work towards that direction and PR to your branch.

What do you think?

[jen-huang]

it seems that maybe the more durable solution, and what I lean towards, would be to have agentPolicyService.create for agentless policies always use the ID constants for the default output and fleet server host for the cloud environments

I would be in favor of continuing with the patch you have here that reads from the policy's fleet_server_host_id. With the work in #218905, the client-side request that creates the agent policy should always be made with this field set, and the code executed at setup (in agentless_settings_ids.ts should correct any policy that doesn't have this set.

This will ensure that the fleet_server_host_id field is always the source of truth. If we use constants on server-side during create time, instead of using this field, may cause confusion if the two ever diverge for whatever reason.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[jen-huang]

Thanks for the fix! 🚀

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: a3b2c18

Metrics [docs]

✅ unchanged

History

• 💛 Build #313729 was flaky e1f26a1

[kibanamachine]

Starting backport for target branches: 9.1

https://github.com/elastic/kibana/actions/runs/15976933896

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	9.1

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation