web: add reverse proxy support

[kdihalas]

Summary

Add a generic ReverseProxy authentication provider for the Flux Operator Web UI.

This allows identity-aware proxies such as Tailscale, oauth2-proxy, Pomerium, or Cloudflare Access to authenticate users and pass their identity to the Web UI through HTTP headers.

The user identity is then used with the existing Kubernetes impersonation and RBAC flow.

What changed

• Added ReverseProxy as a supported authentication type.
• Added configurable headers for username, display name, and groups.
• Added support for default groups when the proxy does not provide any.
• Added trusted proxy IP and CIDR validation.
• Added middleware that:
  • verifies the direct proxy address
  • extracts and normalizes user identity
  • creates the impersonated Kubernetes client
  • stores the user session in the request context
• Added validation and unit tests.
• Updated the docs

Example

authentication:
  type: ReverseProxy
  reverseProxy:
    headers:
      username: X-User-Login
      name: X-User-Name
      groups: X-Groups
    defaultGroups:
      - flux-users
    trustedProxies:
      - 10.42.0.0/16

Security

Identity headers are only trusted when the direct TCP peer matches a configured trusted proxy.

X-Forwarded-For and similar forwarded headers are intentionally not used for this check, since they can be spoofed by clients.

The Web UI should still be exposed only through the trusted proxy, ideally with a NetworkPolicy preventing direct access.

Assisted-by: chatgpt/5.6-sol

[matheuscscp]

I think we definitely want to support these use cases, my major concern with this PR is the config API proposed for the feature significantly deviating from what we currently have for OAuth. In OAuth we feed data to CEL expressions for validation and extraction of the user features (i.e. username, groups, name...). I think we can model this API very closely to how we do it for OAuth via CEL expressions. Instead of feeding JWT claims to the expressions, here we feed the HTTP headers. Pls propose an API that is as close as possible to OAuth.

[kdihalas]

I think we definitely want to support these use cases, my major concern with this PR is the config API proposed for the feature significantly deviating from what we currently have for OAuth. In OAuth we feed data to CEL expressions for validation and extraction of the user features (i.e. username, groups, name...). I think we can model this API very closely to how we do it for OAuth via CEL expressions. Instead of feeding JWT claims to the expressions, here we feed the HTTP headers. Pls propose an API that is as close as possible to OAuth.

Thanks for the feedback, will work on this and update the PR