iOS intake support: auth handling and rate limiting

[simitt]

The iOS agent uses the opentelemetry Intake support of the APM Server to send apm events, rather than the RUM intake. This raises some questions related to auth handling and rate limiting:

• Whenever apm-sever.api_key.enabled: true or an apm-server.secret_token is configured, a valid API Key or secret token needs to be sent with the request, also when sent via opentelemetry intake. Investigate how to handle this for requests from the iOS intake.

• Investigate whether some similar rate limiting as currently enabled for RUM endpoints should be enabled for iOS requests.

[axw]

My current thinking is to introduce a formal concept of "anonymous access", along the lines of what is supported by Elasticsearch: https://www.elastic.co/guide/en/elasticsearch/reference/current/anonymous-access.html

While we're at it, we could group the existing auth types into a new group:

apm-server:
  #auth:
    #secret_token:
    #api_key:
      #enabled: false
      #limit: 100
    #anonymous:
      #allow_rum: false
      #allow_mobile: false
      #allow_service_names: []
      #event_rate:
        #limit: 300
        #cache_size: 1000

By setting allow_rum: true, we would allow unauthenticated HTTP requests to /config/v1/rum/agents, /intake/v2/rum/events, and /intake/v3/rum/events.

By setting allow_mobile: true, we would allow unauthenticated OTLP/gRPC requests as long as they can be identified as originating from an iOS agent.

For both RUM and iOS, requests could be forged so that the client appears to be one of the expected agent types. It is already the case that you can disable/enable the RUM endpoints, which is effectively the same as enabling/disabling unauthenticated access. The same applies to OTLP/gRPC: to combat abuse we can (for example) check for an expected User-Agent string, as opposed to checking the client requested /intake/v2/rum/events rather than /intake/v2/events.

[axw]

Another option would be to make it a bit more generic, and define the allowlist in terms of agent name. e.g.

apm-server:
  #auth:
    #anonymous:
    #  allow_agent: ["rum-js", "iOS/Swift"]
    #  allow_service: [] 

It's no big deal to have "rum-js" in the list by default since RUM is disabled by default. Having iOS in there requires discussion.

Since iOS goes through the same OTLP/gRPC endpoint as authorized backend agents, we would either enable it by default (with rate-limiting for requests without the Authorization header) and filter on agent name after decoding/translating; or disallow iOS by default and document how to enable it.

[simitt]

The anonymous auth concept sounds good, +1 on having one concept for rum and mobile. The second variant with explicitly configuring the allow_agent seems more future proof and is aligned with the provided allow_service option.
In 7.x rum is disabled by default, changing this seems like a logical breaking change, so I suggest to keep disabled by default (up until 8.0).