Closed strawgate closed 2 weeks ago
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)
https://github.com/elastic/beats/pull/39709 was only in 8.14 and https://github.com/elastic/beats/pull/39722 to bring it to main was never merged or backported.
Issue was hit in version Elasticsearch 8.15.2, with at least these integrations.
Crowdstrike (FDR) 1.42.2 section "Collect CrowdStrike Falcon Data Replicator logs (input: aws-s3) > Falcon Data Replicator logs"
Cisco Umbrella 1.26.2. section "Collect logs from Cisco Umbrella > Cisco Umbrella Logs"
Workaround required deleting the value located in the "Endpoint" field
Are there any other integrations that we should be aware of that could be impacted?
Any integration that can use the aws-s3 input would be affected, here's a preliminary list I generated quickly:
8.15 no longer has the fix for AWS S3 endpoint handling that was present in 8.14
8.15: https://github.com/elastic/beats/blob/2f0dda8c0d9a1bd644fcdf1ebd41f32bfc7a907d/x-pack/filebeat/input/awss3/input.go#L51-L60
8.14: https://github.com/elastic/beats/blob/7b6cfad6ad3f767ed277bd23317d63449173ec27/x-pack/filebeat/input/awss3/input.go#L83-L104
In AWS, the
endpoint
field is supposed to act kind of like a "base url" where service URLs are built using the value in the endpoint field. So when the SQS client makes a request, an endpoint field ofs3.us-east1.amazonaws.com
is transformed intosqs.us-east1.amazonaws.com
, etc.The 8.15 code forces all endpoints to use the value in the
endpoint
field instead of relying on the resolver to use the endpoint to "build" each service's endpoint (s3, sqs, etc). In the example above, this would cause the SQS client to directly querys3.us-east1.amazonaws.com
Even the 8.14 code has an issue that crops up with some customers. We should likely switch to only using a custom endpoint resolver when a user explicitly tells us to, for example by introducing a new setting called "static endpoint" or something similar, that when set to true, sets the endpoint resolver as it is set currently. This would be a breaking change.
An alternative would be introducing a setting called, "dynamic_endpoint" or something similar which, when set, sets the
endpoint
field without using a resolver.