docs: Clarify anonymous authentication details

[bmorelli25]

Summary

The docs should be updated to better reflect that, by default, RUM related auth handling is disabled, but enabled as soon as auth handling is generally enabled.

The goal of this PR is to better clarify when and why anonymous requests to the APM Server are accepted or rejected. Here's the thought process—and please correct me if I'm wrong:

We have two anonymous authentication pages in the docs. One is for the APM integration and one is for standalone APM Server. This PR updates these pages to clarify that the APM Server’s default response to anonymous requests depends on whether an API key or Secret Token has been configured. If and only if an API key or Secret token has been configured, 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.

In addition to the above pages, the standalone APM Server documentation has a configuration reference for anonymous authentication. Previously, this page stated:

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.

IIUC, this is only true if a secret token or API key has been configured. I've reworked the text on this page to better reflect this.

I think those are the important bits. Have a good weekend 👋

Related

• Follows up on @lucabelluccini's PR (thanks!) [DOCS] Specific callout to anonymous settings & auth in APM Server legacy #10076
• Closes docs: clarify when auth is enabled/disabled in the anonymous auth guide #9969

[apmmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-03-24T00:16:52.318+0000

• Duration: 12 min 28 sec

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate and publish the docker images.

• /test windows : Build & tests on Windows.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[simitt]

Thank you!

[lucabelluccini]

I think the only point which is not clear now is explain what happens if APM Server/Integration allows both api key & secret token.

At least from elastic/apm#183 and from some tests we did: the api key is sent out by the agent if both are configured and so the event should be accepted/allowed

[simitt]

what happens if APM Server/Integration allows both api key & secret token.

The server behaves the same if only the api key or secret token or both are enabled. The differentiator is whether or not any auth is required by enabling at least one of them.

At least from elastic/apm#183 and from some tests we did: the api key is sent out by the agent if both are configured and so the event should be accepted/allowed

I'm not sure I follow; the apm agent will use whatever is configured for the agent (not in the apm-server) - api key, secret token or nothing, and this can be different between apm agents.

[bmorelli25]

To add to Silvia's response, we mention in the docs that

If both API keys and a secret token are enabled, APM agents can choose whichever mechanism they support.

[bmorelli25]

@Mergifyio backport 8.7

[mergify]

backport 8.7

✅ Backports have been created

• #10521 [8.7] docs: Clarify anonymous authentication details (backport #10227) has been created for branch 8.7

[bmorelli25]

@Mergifyio backport 8.7

[mergify]

backport 8.7

✅ Backports have been created

• #10521 [8.7] docs: Clarify anonymous authentication details (backport #10227) has been created for branch 8.7