Anonymous authenticationedit

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’ve already upgraded, see Anonymous authentication.

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. The APM Server’s default response to these these requests depends on its configuration:

Configuration Default

An API key or secret token is configured

Anonymous requests are rejected and an authentication error is returned.

No API key or secret token is configured

Anonymous requests are accepted by the APM Server.

In some cases, however, it makes sense to allow both authenticated and anonymous requests. For example, it isn’t possible to authenticate requests from front-end services as the secret token or API key can’t be protected. This is the case with the Real User Monitoring (RUM) agent running in a browser, or the iOS/Swift agent running in a user application. However, you still likely want to authenticate requests from back-end services. To solve this problem, you can enable anonymous authentication in the APM Server to allow the ingestion of unauthenticated client-side APM data while still requiring authentication for server-side services.

When an API key or secret token is configured, anonymous authentication must be enabled to collect RUM data. To enable anonymous access, set either apm-server.rum.enabled or apm-server.auth.anonymous.enabled to true.

Because anyone can send anonymous events to the APM Server, additional configuration variables are available to rate limit the number anonymous events the APM Server processes; throughput is equal to the rate_limit.ip_limit times the rate_limit.event_limit.

See Anonymous authentication for a complete list of options and a sample configuration file.