PROXY Protocol v2 logging support

[jantman]

Feature Request:

Vault currently supports using a client IP from a PROXY protocol header via the work done in #3098 and modified in #3195.

We're looking at leveraging a new AWS solution, PrivateLink, a SDN construct that allows securely exposing services behind Network Load Balancers (NLBs) in a "service provider" account, to multiple clients in separate AWS accounts - without network-level connections (i.e. it provides a virtual endpoint in client accounts, that routes traffic directly to a load balancer in a service provider account).

Traffic from such connections is seen as coming from a single source IP (the load balancer node), and the only information about which client it's coming from is encoded in a custom Type-Length-Value vector in a PROXY v2 header, per these docs from AWS.

I'll admit that I doubt many people outside of AWS have need for this, and I'm not entirely sure what would be involved in parsing this out or how that would be configured. But support for logging PROXYv2 fields (maybe in a way similar to how request headers are logged, via #2321) would be extremely helpful in this situation.

[JayH5]

Just to add, NLBs are not only used for PrivateLink and can be used instead of Elastic/Classic Load Balancers (ELB). One big advantage of NLBs over ELBs is that a single NLB will have fixed private IPs, whereas ELB private IPs can change over time. Why this is important is that it means that NLB private IPs can be used for the proxy_protocol_authorized_addresses setting, but ELB ones cannot.

ELB supports only PROXY protocol v1, while NLB supports only v2.

To add v2 support to Vault it would first need to be added to the upstream library, go-proxyproto.

[thenoid]

I would like see this implemented as well, currently in a similar boat as the OP

[craigday]

I would like to see this as well. Just ran into this when adding IP constraints to an AppRole and was not seeing the client's IP addresses. We use NLB end expose Vault across multiple VPCs using endpoint services.

[thorix]

We are having to use HAProxy to "fix" this problem. HAProxy isn't decrypting the traffic so some errors do not get returned correctly. This still seems to be a preferable solution.

[daveadams]

Looks like there's an alternative implementation that supports proxy protocol v1 and v2: https://github.com/pires/go-proxyproto. It doesn't have exactly the same semantics as Armon's v1-only version, but it's pretty close. Support for proxy protocol v2 would be incredibly useful for logging purposes in our PrivateLink-deployed Vault clusters.

[pires]

Looks like there's an alternative implementation that supports proxy protocol v1 and v2: https://github.com/pires/go-proxyproto. It doesn't have exactly the same semantics as Armon's v1-only version, but it's pretty close. Support for proxy protocol v2 would be incredibly useful for logging purposes in our PrivateLink-deployed Vault clusters.

Hashicorp team has contributed to said repo - thanks, folks! - and seem to have adopted it for Boundary. I guess it's just a matter of priorities but it seems doable. I'm happy to help anyone wanting to pick this one up.

[vishalnayak]

@pires Are you still interested in tackling this?

[pires]

I can try and take a look but I really only offered help if anyone was willing to take the work :D it's been a couple years since I last looked at Vault's code.