Anonymous auth configuration optionsedit

This documentation refers to configuring the standalone (legacy) APM Server. This method of running APM Server will be deprecated and removed in a future release. Please consider upgrading to Fleet and the APM integration. If you’re using Fleet and the Elastic APM integration, please see Input settings instead.

Elastic APM agents can send unauthenticated (anonymous) events to the APM Server. This is useful for agents that run on clients, like the Real User Monitoring (RUM) agent running in a browser, or the iOS/Swift agent running in a user application.

Example configuration:

apm-server.auth.anonymous.enabled: true
apm-server.auth.anonymous.allow_agent: [rum-js]
apm-server.auth.anonymous.allow_service: [my_service_name]
apm-server.auth.anonymous.rate_limit.event_limit: 300
apm-server.auth.anonymous.rate_limit.ip_limit: 1000

The anonymous access configuration is ignored if authenticated communication is disabled.

Real User Monitoring (RUM)edit

Anonymous authentication must be enabled to collect RUM data. For this reason, anonymous auth will be enabled automatically if apm-server.rum.enabled is set to true, and apm-server.auth.anonymous.enabled is not explicitly defined.

See Real User Monitoring (RUM) for additional RUM configuration options.

Mitigating malicious requestsedit

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

Use the allow_agent and allow_service 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 with rate_limit.event_limit. 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.

Configuration referenceedit

Specify the following options in the apm-server.auth.anonymous section of the apm-server.yml config file:

enablededit

Enable or disable anonymous authentication.

Default: false (disabled)

allow_agentedit

A list of permitted APM agent names for anonymous authentication. Names in this list must match the agent’s agent.name.

Default: [rum-js, js-base] (only RUM agent events are accepted)

allow_serviceedit

A list of permitted service names for anonymous authentication. Names in this list must match the agent’s service.name. This can be used to limit the number of service-specific indices or data streams created.

Default: Not set (any service name is accepted)

rate_limit.ip_limitedit

The number of unique IP addresses to track in an LRU cache. IP addresses in the cache will be rate limited according to the rate_limit.event_limit setting. Consider increasing this default if your application has many concurrent clients.

Default: 1000

rate_limit.event_limitedit

The maximum number of events allowed per second, per agent IP address.

Default: 300