SPIRE server incorrectly rate limits when behind a load balancer that doesn't support client IP preservation

[jeffherald]

If the SPIRE server API is placed behind a load balancer that doesn't support or can't have client IP preservation enabled, it will rate limit on the load balancer IPs instead of caller (agent) IPs which can lead to limits being incorrectly applied.

Because SPIRE server terminates TLS, modifying requests before they reach the server isn't feasible. One possible solution would be to add proxy protocol support which would allow the caller IP to be encoded in to requests and allow the server to enforce rate limits properly.

[sorindumitru]

We'll have to look a bit more at the proxy protocol and how it works with gRPC, but this sounds ok in principle. If you have any more details on that, they would be welcomed.

Another thing we could do is to rate limit on the caller SPIFFE ID, if that is available. It wouldn't work with node attestations, since there's not SPIFFE ID there, but it would cover most other APIs. It would have the benefit of working out of the box. We could probably do both of these things.

[sorindumitru]

We looked a bit at this and we think it's worth having. We found this library that seems supported and might provide everything we need to handle that PROXY protocol. @jeffherald Would you be open to working on this?

[rausingh-rh]

Hi @sorindumitru @jeffherald,

I'd like to pick this up if no one is currently working on it. Based on the discussion here, my plan is to:

1. Add proxy protocol support using the library (as suggested). This would wrap the TCP listener in runTCPServer with a proxyproto.Listener when enabled, so conn.RemoteAddr() returns the real client IP. The existing rate limiting middleware doesn't need changes since it already reads from the peer address.
2. Opt-in configuration via a new listen_proxy_protocol option under the server {} block (defaults to false). This must be explicitly enabled since the server and LB need to agree on proxy protocol usage.

I'm also happy to look into rate limiting by caller SPIFFE ID as a follow-up (as @sorindumitru mentioned), but I think proxy protocol makes sense as a self-contained first PR since it covers all RPCs including unauthenticated ones like node attestation.

Let me know if this approach sounds good.