Expand dashboard telemetry security guidance

src/frontend/src/content/docs/dashboard/security-considerations.mdx

@@ -50,6 +50,12 @@ When the dashboard is launched by an Aspire AppHost, the OTLP and telemetry API
 
 The dashboard collects telemetry through an [OTLP (OpenTelemetry protocol)](https://opentelemetry.io/docs/specs/otel/protocol/) endpoint. Apps send telemetry to this endpoint, and the dashboard stores the external information it receives in memory, which is then accessible via the UI.
 
+:::danger[Accept telemetry only from trusted sources]
+Treat the OTLP endpoint as an ingestion service, not as a public telemetry collector. A malicious or compromised sender can submit large volumes of telemetry or maliciously shaped telemetry, such as data with many attributes, long values, large numbers of span events, or high-cardinality metrics. Receiving, decoding, validating, and processing this data consumes network bandwidth, CPU, and memory, even when the dashboard later rejects, truncates, or evicts it.
+
+An untrusted sender can also perform **telemetry spoofing** by claiming another app's identity in sender-controlled resource attributes. For example, a malicious app could use the same `service.name` as a trusted app and send fabricated logs, traces, or metrics that appear to come from that app.
+:::
+
 To prevent untrusted apps from sending telemetry to Aspire, the OTLP endpoint should be secured. The OTLP endpoint is automatically secured with an API key when the dashboard is started by Aspire tooling. Additional configuration is required for standalone mode.
 
 API key authentication can be enabled on the telemetry endpoint with some additional configuration:
@@ -174,12 +180,22 @@ aspire dashboard run `
 
 When API key authentication is configured, each request to the telemetry API must include a valid `x-api-key` header. If the API is enabled without configuring an auth mode or API key, it defaults to `Unsecured` and a warning is logged at startup.
 
-## Memory exhaustion
+## Resource exhaustion
 
-The dashboard stores external information it receives in memory, such as resource details and telemetry. While the number of resources the dashboard tracks are bounded, there isn't a limit to how much telemetry apps send to the dashboard. Limits must be placed on how much information is stored to prevent the dashboard using an excessive amount of memory and exhausting available memory on the current machine.
+The dashboard uses resources for every telemetry payload it receives. Stored resource details and telemetry consume memory, while ingesting telemetry also consumes network bandwidth and CPU. A burst of telemetry, many concurrent senders, or payloads designed to require excessive processing can degrade dashboard availability or exhaust resources on the host.
 
 ### Telemetry limits
 
-To help prevent memory exhaustion, the dashboard limits how much telemetry it stores by default. For example, there is a maximum of 10,000 structured log entries per resource. Once the limit is reached, each new log entry received causes an old entry to be removed.
+The dashboard limits the count and size of telemetry it stores. For example, there is a maximum of 10,000 structured log entries shared across resources. Once the limit is reached, each new log entry received causes an old entry to be removed. Configurable limits also constrain attributes, span events, tracked resources, traces, and metric data points.
+
+Storage limits reduce long-lived memory use, but they aren't admission-control or rate limits. The dashboard still incurs some cost to receive and process telemetry before applying storage limits, and the limits don't cap the total amount of telemetry that senders can transmit over time. Consequently, storage limits reduce but don't eliminate the risk of resource exhaustion.
+
+Use defense in depth when accepting telemetry:
+
+- Require API key authentication and rotate a key if an untrusted party might have obtained it.
+- Limit OTLP endpoint access with network controls such as firewall rules or private networks.
+- Apply request-size, rate, and concurrency limits at a gateway or reverse proxy when senders aren't fully trusted.
+- [Configure telemetry limits](/dashboard/configuration/#telemetry-limits), including attribute length and span event count, for the expected workload.
+- Monitor the dashboard host's CPU and memory use, and isolate the dashboard from critical workloads when appropriate.
 
-Configuration can customize telemetry limits.
+Review these controls whenever the expected telemetry volume or the set of trusted senders changes.