Add Hostname and other identifier flags to fleetd

[pacamaster]

- How might this have a positive effect on your organization? Reduces the number of calls hitting the enroll endpoint and have less noise to filter through, when there are errors.

- What is the current situation? Why does the current situation hurt? Orbit/fleetd supports only uuid (forwarded from default provided) and instance for --host_identifier. Most situations can get away with instance (using the backing store) but, there are some situations where hostname would be a better choice or even ephemeral when working with VMs. hostname, uuid, ephemeral, instance, specified are all supported by osquery and can be set with agent_options. Trouble is that when setting to one of the identifiers outside of uuid and instance, "osquery" and "orbit" will both enroll in Fleet and cause issues with the enrollment cycling and showing an enrollment for orbit and osquery.

- What are you doing right now to work around this issue? What's non-ideal about it? Currently, tagged client is running instance but this will still cause trouble in some situations. Infrastructure for their VMs already has unique hostnames and makes sure that the hostnames are not duplicated.

Problem

TODO

Potential solutions

1. Add hostname to a supported flag in Orbit with the note/warning/document that if having duplicate hostnames, will cause enrollment issues
2. Add support for other identifiers for to have parity with osquery

[JoStableford]

Related to a Slack conversation

[noahtalerman]

Hey @pacamaster thanks for filing this!

Sounds like the smallest change we could make it adding supporting for settings instance for --host_identifier.

hostname, uuid, ephemeral, instance, specified are all supported by osquery and can be set with agent_options

@lucasmrod I remember at some point we chatted about supporting all the options osquery supports but I can't remember why we didn't.

I think we thought only adding instance was simpler and we could add more later.

Were there downsides to adding support for all the options?

[lucasmrod]

Correct, we only added instance to reduce scope/risk.

• --host-identifier=hostname: (I believe it's possible.) Orbit would fetch this from system_info.hostname.
• --host-identifier=specified: (I believe it's possible.) Orbit would also need an extra cli-arg/env to set the specified value, e.g. --specified_identifier, which is the corresponding osquery flag name.
• --host-identifier=ephemeral: (At first sight I believe it's not possible.) I don't know how Orbit could get this from osquery (as it's a UUID generated at osqueryd process start time and not persisted - it just resides in osqueryd's memory AFAICS).

PS: Re ephemeral, we can maybe simulate ephemeral by having Orbit generate the random UUID and passing it to osqueryd as --host_identifier=specified --specified_identifier=$RANDOM_GENERATED_BY_ORBIT_AT_START_TIME. But would like to know more about the user case around using ephemeral instances.

[noahtalerman]

Hey @pacamaster, heads up, we brought this into the upcoming design sprint (4.49).

[uniit]

Our use case involves overriding the display name based on an environment variable available on the managed fleet of servers. This would greatly simplify automation on our end. Currently, the main hosts tab is ineffective since it displays random hostnames. Our clients do not wish to override them, so we must create a query to retrieve the unique environment variable and use a script to extract the host_id for automation.

Implementing specified_identifier should resolve this issue.