Add PROXY protocol support for rate limiting behind load balancers

[raajheshkannaa]

Summary

When SPIRE server sits behind a load balancer that doesn't preserve client IPs, per-IP rate limiting treats all agents as one client (the LB IP). This adds opt-in PROXY protocol support so the server can extract real client IPs from the PROXY protocol header.

• Adds listen_proxy_protocol config option (defaults to false)
• Wraps the TCP listener with github.com/pires/go-proxyproto when enabled, so conn.RemoteAddr() returns the real client IP
• No changes to rate limiting middleware needed, since it already reads from the gRPC peer address
• The library was recommended in the issue discussion by @sorindumitru

Configuration

server {
    listen_proxy_protocol = true
}

This must only be enabled when the load balancer is configured to send PROXY protocol headers.

Fixes #6678

Test plan

• New unit test verifying PROXY protocol listener extracts real client IP from v1 header
• Config parsing tests for listen_proxy_protocol in both file config and server config
• Existing endpoint and rate limiting tests pass unchanged

[amartinezfayo]

I'm thinking that the boolean opt-in makes sense for the cooperative case where the operator controls the network path between the load balancer and SPIRE Server. One thing worth considering though is the adversarial scenario: without a ConnPolicy on the listener, I believe that the library defaults to accepting PROXY protocol headers from any connection. If a client can reach the SPIRE Server port directly (bypassing the load balancer), they could forge an arbitrary source IP in the header and rotate through fake IPs to evade rate limiting.

One way to address this without adding a second config option would be to replace listen_proxy_protocol with something like proxy_protocol_trusted_cidrs (that's a list of CIDRs). When the list is non-empty, PROXY protocol is enabled and restricted to those sources via the library's ConnPolicy; when empty or unset, it's disabled. That way there's still a single knob, and it becomes impossible to enable the feature without specifying who's trusted.

What do you think? Is there a scenario in your use case where you'd need PROXY protocol enabled but wouldn't be able to enumerate the trusted source IPs?

[raajheshkannaa]

Good call. Replaced listen_proxy_protocol with proxy_protocol_trusted_cidrs (list of CIDRs). When non-empty, PROXY protocol is enabled and a ConnPolicy built via StrictWhiteListPolicy rejects connections from any source not in the list. When empty/unset, PROXY protocol is disabled. Single knob, forces enumeration of trusted sources.

Also added a test that verifies untrusted sources get rejected.

For our use case we always know the LB IPs, so enumerating trusted CIDRs is not a problem.