Add ability to change RUM intake endpoint path

[nugroho-exp]

Hi,

We have an issue that our RUM script gets blocked by ad blocker (see elastic/apm-agent-rum-js#1078). There is a workaround in the provided javascript client to use serverUrlPrefix but there is no option in the APM server configuration to change intake endpoint (/intake/v2/rum/events).

We tried to add a reverse proxy in front of Elastic cloud APM load balancer but it seems the Elastic Cloud load balancer drops X-Forwarded-For header (I think for security reason: https://www.elastic.co/guide/en/apm/guide/8.3/anonymous-auth.html#derive-client-ip-concerns) so in the APM UI we always get our proxy IP address as Client IP address which we do not want.

It would be nice if there is an option on APM server to configure the intake endpoint path.

I guess it is possible to host our own APM server and add proxy in front of it but that defeats the purpose why we want to have a managed cloud solution (including APM service) in the first place.

APM Server version: v8.3.2 (Managed by Fleet)
Environment: Managed Elasticsearch Service

Thank you.

Regards,
Nugroho

[axw]

@nugroho-exp sorry for the delay in responding.

I've been thinking about your request, and wanted to let it marinate for a bit in case any alternatives occurred to me, but the bottom line is that we're not going to make the RUM intake (or any other routes) configurable.

We tried to add a reverse proxy in front of Elastic cloud APM load balancer but it seems the Elastic Cloud load balancer drops X-Forwarded-For header (I think for security reason: https://www.elastic.co/guide/en/apm/guide/8.3/anonymous-auth.html#derive-client-ip-concerns) so in the APM UI we always get our proxy IP address as Client IP address which we do not want.

That's correct: the issue is basically that if the client IP can be spoofed (e.g. by setting X-Forwarded-For to a random IP address), then a client could bypass rate limiting and potentially take down your deployment. This is only issue if the origin of the header is an untrusted agent, such as a browser or a script executing curl.

If you were to run a reverse proxy in front of Elastic Cloud, then in theory you could say it's trusted and allow X-Forwarded-For headers to be passed through. I believe this is not possible today, and would require an enhancement to Elastic Cloud where you could set an allowlist (e.g. an IP range) for honouring X-Forwarded-For headers. I would recommend you open a support ticket in Elastic Cloud asking if this is possible, or otherwise asking for an enhancement.