feat: protect /metrics endpoint with auth and IP allowlist

[obanai9]

Summary

Gates the /metrics Prometheus endpoint behind API key authentication and an optional IP allowlist, preventing public exposure of internal operational data.

Changes

services/api/src/main.rs

• Removed /metrics from public_routes
• Added a dedicated metrics_routes router with metrics_auth_middleware wired from MetricsAuthConfig (built from existing config fields: metrics_public, metrics_allowlist_ips, api_key_auth)

services/api/src/security.rs

• MetricsAuthConfig and metrics_auth_middleware were already implemented; no changes needed
• Added unit tests covering all access-control branches

services/api/tests/security_tests.rs

• Added integration-level HTTP tests: public mode bypass, missing key → 401, valid key → 200, wrong key → 401, IP not in allowlist → 403

Security Behaviour

Scenario	Result
METRICS_PUBLIC=true	Open (no auth) — for trusted internal networks only
Valid x-api-key header, no allowlist	✅ 200
Missing or wrong x-api-key	❌ 401
IP not in METRICS_ALLOWLIST_IPS	❌ 403
IP in allowlist + valid key	✅ 200

Configuration

Env var	Default	Purpose
METRICS_PUBLIC	false	Skip all auth (opt-in, internal clusters only)
METRICS_ALLOWLIST_IPS	(empty)	Comma-separated IP allowlist; empty = no IP restriction
API_KEYS	(empty)	Shared API key(s) checked via x-api-key header

Testing

All new tests are in security.rs (unit) and tests/security_tests.rs (integration).

Closes #456

[drips-wave]

@obanai9 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits