Configure trusted forwarded header peers

[niemyjski]

Previously, the API accepted forwarded client IPs and schemes from any peer. This restricts forwarding to framework loopback defaults plus configured peers, processes headers before their consumers, and normalizes mapped IPv4 addresses for consistent IP-based limits. Dev and prod deployments now discover the selected Azure gateway's delegated association subnet and pass its prefixes into Helm automatically. The configuration helper and its tests live under Security.

Validation: backend build passed with zero warnings/errors; 25 forwarding tests and 48 extension tests passed; 22 deployment/CI tooling tests passed, including real offline dev/prod Helm renders with mocked Kubernetes/Azure responses. No environment access or deployment was performed. Exact-head Website and Build CI passed, including the API and browser test aggregates; publication and deployment jobs were skipped.

Rollout blocker: discovery does not verify the API-visible traffic path or deployment identity permissions; #2668 retains those acceptance checks. Remote proxy installations must configure trust with the upgrade. Known CI issue: #2667 tracks the previously reproduced webhook tracing-provider interference; this change does not fix it.

Configuration, deployment, and verification details

• Both deployment paths run k8s/scripts/discover-forwarded-headers.mjs before Helm upgrade. It reads the gateway selected by the rendered ingress, resolves its association subnet IDs with Azure CLI, and requires matching subnet identity, AGC delegation, and valid non-/0 prefixes. Failed reads or invalid configuration stop the upgrade. The deployment identity needs Kubernetes read access to the selected ApplicationLoadBalancer and Azure subnet read access.
• Generated forwardedHeaders.knownNetworks replaces the entire prior list, including with --reuse-values; the chart emits indexed environment settings and a forward limit of one. Conflicting manual ForwardedHeaders config keys fail rendering rather than silently extending trust. Failed discovery removes stale output. Existing ConfigMap checksums restart app/API pods when configuration changes.
• Manual upgrades must also generate and pass discovery output, as documented in the existing Kubernetes guide. Other proxy topologies retain explicit config.EX_ForwardedHeaders__KnownProxies__0 or config.EX_ForwardedHeaders__KnownNetworks__0 settings. No cluster-wide, Service, controller-pod, or trust-all fallback is used.
• The existing YAML, custom EX_ environment, then command-line configuration pipeline remains. KnownNetworks maps to .NET 10 KnownIPNetworks. Invalid IPs, CIDRs, scalar lists, negative limits, and /0 networks fail with actionable errors. Loopback defaults, default one-hop processing, and zero-disabled mode remain. Containers pin ASP.NET Core 10.0.13; local backend tests used 10.0.12.
• UseForwardedHeaders() remains after error handling and before HTTPS, IP-dependent headers, logging, authentication, and throttling, consistent with Microsoft's ordering guidance. OAuth/MCP public origins remain explicitly configured; host/prefix forwarding, routes, payloads, and WebSocket formats are unchanged.
• Discovery assumes AGC connects directly to the application, using its association subnet. Additional proxies require separate review. Live peer/scheme verification remains outstanding by design.
• Run local deployment tests: node --test tests/ci/shards.test.mjs tests/ci/forwarded-headers-discovery.test.mjs. They require Helm but never call real kubectl or Azure CLI. Backend test classes: Exceptionless.Tests.Security.ForwardedHeadersConfigurationTests and Exceptionless.Tests.Extensions.*.

[github-actions]

Package	Line Rate	Branch Rate	Complexity	Health
Exceptionless.AppHost	23%	23%	128	❌
Exceptionless.Core	78%	69%	10924	✔
Exceptionless.Insulation	51%	43%	370	➖
Exceptionless.Web	86%	71%	9228	✔
Summary	80% (28309 / 35228)	69% (14019 / 20218)	20650	✔