-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Cloud Security] use only available agent versions for Cloudformation and Cloud Shell parameters #166198
[Cloud Security] use only available agent versions for Cloudformation and Cloud Shell parameters #166198
Conversation
Pinging @elastic/kibana-cloud-security-posture (Team:Cloud Security) |
A question to the Fleet team: this logic of using the Kibana version as an agent version for installation steps exists in other places for fleet UI, basically everywhere where |
91d4983
to
f5c39d4
Compare
Pinging @elastic/fleet (Team:Fleet) |
if ( | ||
availableVersions && | ||
availableVersions.length > 0 && | ||
availableVersions.indexOf(kibanaVersion) === -1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joshdover adding you to reviewers as you worked on https://github.com/elastic/kibana/pull/166150/files#diff-de1953cdeee69d71565b65a14751a0dd602ca5e3c8f81b4854113e6b97cc231b
Does this logic make sense? To my understanding, we need to check if the Kibana version is in available versions to support older ESS versions. Or each version of Kibana has JSON with available versions generated in a way, that it only contains the current patch version as the first element. Eg. in the future when the latest major is 8.13.0 and there is an 8.11.2 or smth released, will JSON contain versions lower than 8.11.2 or it actually will include all 8.12.x and 8.13.x?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my understanding the JSON generated during the build will include all versions released up to that point in time, and nothing later.
On ESS/Stateful, we also add the current Kibana version which is already handled server side. I don't think this change here is needed, but I may not be understanding fully. Could you explain exactly the scenario that isn't currently working?
In any case, if a change is needed, please make it on the server side in https://github.com/elastic/kibana/blob/main/x-pack/plugins/fleet/server/services/agents/versions.ts so that it can be applied everywhere (there are some other backend pieces that consume this logic).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this test case https://github.com/elastic/kibana/pull/166198/files#diff-949758c47e64dee7bf348fa03e9146d8b87a71a62f37bee09db163c46569675cR22 captures the scenario. Without the change, the returned version would be 8.9.0 while to my understanding we want an earlier version to be picked up.
If I'm not missing anything about this scenario, the change on the server side would be to filter out all the versions greater than the current Kibana version and I guess it will break other places in fleet when we need released agent versions greater than the current Kibana version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current logic only returns released agent versions in serverless, so I don't think you need any change to fix this for serverless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@juliaElastic the thing I struggle to understand is how we deal with the patch version to the older version of the stack. Eg. when there are 8.12.0, 8.11.0 released but the user updates to say 8.9.3 which was released. The list of released versions will contain 8.12.0 as the first element and this version then will be picked up for all the artifact links in the Fleet UI. So in 8.9.3 Kibana, the links will point to the 8.12.0 agent which has been released but may not be compatible with this old version. Do we see this as an issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I don't know if this is being tested, maybe from the Agent side? cc @cmacknz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fleet server won't let agents that are newer than Fleet server's version connect, there is a version constraint enforced as part of the check in.
We plan to remove this constraint eventually but this is still the case today and for all previously released versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then if read @cmacknz's comment correctly we do actually need to make sure that we pick the agent version that matches the Kibana version if this version exists in the list of released agent versions. If we just keep it as it is now (picking the latest released agent version from the list no matter of the Kibana version) it will cause agents not to be able to connect to fleet servers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If kibana version is not in the list of agent versions, should the logic return the latest agent version that is <= kibana version? It's not a likely scenario, though might happen if kibana and agent uses different versions eventually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@juliaElastic good point, I changed the logic to accommodate for that and added a test case
…d Security integrations (#166485) ## Summary fixes - elastic/security-team#7557 using the new `useAgentVersion` hook to get the agent version to prefill in the Cloudformation template There is already a PR with the same fix #166198 but as it also changes the logic of `useAgentVersion` itself, it might take some time to align. This PR only fixes the immediate issue we have in Serverless
24c6566
to
f0d74df
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…int-to-non-existing-agent-artifact-in-serverless
I see that there is also logic on the server side in |
…int-to-non-existing-agent-artifact-in-serverless
…int-to-non-existing-agent-artifact-in-serverless
…int-to-non-existing-agent-artifact-in-serverless
…int-to-non-existing-agent-artifact-in-serverless
…int-to-non-existing-agent-artifact-in-serverless
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
Summary
fixes
instead of using Kibana version for Cloudformation and Cloud Shell params in CNVM and CSPM integrations, check if the version of an agent that matches the current Kibana version actually available as an artifact. Relevant for serverless, where Kibana version points to not-yet released versions of Elastic Agent.
Checklist