Conversation
michalpristas
added
the
Team:Elastic-Agent-Control-Plane
michalpristas
added
the
backport-active-9
|
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
They all still have a version don't they? Looking at the paired elastic/fleet-server#6864 where you'd need ECH deployments to update for this to work, what problem are you solving that requires both of these? IIRC the original motivation for this was to get agentless to show in proxy telemetry, you just need to insert the word agentless somewhere don't you? Is the problem that you are injecting the user agent yourself and you don't know the agent version when you do that (is this actually true? You know what container tag you deployed don't you?)? I am not opposed to the changes in isolation but I worry this is creating a series of incompatibilities it would be better to avoid instead. |
|
well for this to work by "placing agentless somewhere" we would need to make it part of the version. for this to work it would need to be |
We know the version for ECH, and we have the image tags, so for ECH presumably we could just append For serverless, I think I can see a problem, as we don't actually have a version there -- the image tag doesn't contain a version, so it is not suitable to be inserted the same way into the user agent string. So, how would we construct a valid user agent string in this scenario? Is this a fair understanding of the limitations on the agentless side regarding agent versions and the ability to construct compatible user-agent strings without changing the validation? |
|
yes what you described @nkvoll is correct, ECH is not problematic we have stack version, but Serverless is very unknown, no stack version, and useless tag. so i see 2 options here maybe. handling this from opposite side, and dealing with a problem inside agent itself-if marked as agentless append this info to a header itself. i'd be in favor additionally on top of this work to introduce a restriction to override user agent from FLEET_HEADERS or --headers as this is user facing and can turn agent useless (no checkin, no enroll will happen) |
Agentless has it's own container, so you can change or set the user agent at build time based on the build time stack version in the agent repository can't you? There isn't a need to do this in the controller necessarily. |
|
If you want to try doing it the current way in serverless and check if it works we can also do that, might be faster than debating about how to do it instead. I don't have a strong opinion here I was just surprised to see that Fleet Server needed a change as well, and began wondering if anything else might or if this would limit us later in some way. |
5 participants
In order to use custom header for agentless deployments, we need to provide some way for fleet server to detect agent version
at this point server parser User agent header and expects
Elastic Agent v1.2.3this is no longer true.Adding
Elastic-Agent-Versionheader that can use as a fallback for cases when version is not included in User Agent