Anonymous authenticationedit

Elastic APM agents can send unauthenticated (anonymous) events to the APM Server. An event is considered to be anonymous if no authentication token can be extracted from the incoming request. By default, these anonymous requests are rejected and an authentication error is returned.

In some cases, however, it makes sense to allow anonymous requests — for example, when using the Real User Monitoring (RUM) agent running in a browser, or the iOS/Swift agent running in a user application, it is not possible to hide or protect a secret token or API key. Thus, enabling anonymous authentication is required to ingest client-side APM data.

Configuring anonymous authenticationedit

There are a few configuration variables that can mitigate the impact of malicious requests to an unauthenticated APM Server endpoint.

Use the Allowed anonymous agents and Allowed anonymous services configs to ensure that the agent.name and service.name of each incoming request match a specified list.

Additionally, the APM Server can rate-limit unauthenticated requests based on the client IP address (client.ip) of the request. This allows you to specify the maximum number of requests allowed per unique IP address, per second.

Deriving an incoming request’s client.ip addressedit

The remote IP address of an incoming request might be different from the end-user’s actual IP address, for example, because of a proxy. For this reason, the APM Server attempts to derive the IP address of an incoming request from HTTP headers. The supported headers are parsed in the following order:

  1. Forwarded
  2. X-Real-Ip
  3. X-Forwarded-For

If none of these headers are present, the remote address for the incoming request is used.

Using a reverse proxy or load balanceredit

HTTP headers are easily modified; it’s possible for anyone to spoof the derived client.ip value by changing or setting, for example, the value of the X-Forwarded-For header. For this reason, if any of your clients are not trusted, we recommend setting up a reverse proxy or load balancer in front of the APM Server.

Using a proxy allows you to clear any existing IP-forwarding HTTP headers, and replace them with one set by the proxy. This prevents malicious users from cycling spoofed IP addresses to bypass the APM Server’s rate limiting feature.