PROXY protocol support
PFA a simple patch that implements support for the PROXY protocol.
This is a protocol common and very light weight in proxies and load
balancers (haproxy is one common example, but also for example the AWS
cloud load balancers). Basically this protocol prefixes the normal
connection with a header and a specification of what the original host
was, allowing the server to unwrap that and get the correct client
address instead of just the proxy ip address. It is a one-way protocol
in that there is no response from the server, it's just purely a
prefix of the IP information.
Using this when PostgreSQL is behind a proxy allows us to keep using
pg_hba.conf rules based on the original ip address, as well as track
the original address in log messages and pg_stat_activity etc.
The implementation adds a parameter named proxy_servers which lists
the ips or ip+cidr mask to be trusted. Since a proxy can decide what
the origin is, and this is used for security decisions, it's very
important to not just trust any server, only those that are
intentionally used. By default, no servers are listed, and thus the
protocol is disabled.
When specified, and the connection on the normal port has the proxy
prefix on it, and the connection comes in from one of the addresses
listed as valid proxy servers, we will replace the actual IP address
of the client with the one specified in the proxy packet.
Currently there is no information about the proxy server in the
pg_stat_activity view, it's only available as a log message. But maybe
it should go in pg_stat_activity as well? Or in a separate
pg_stat_proxy view?
(In passing, I note that pq_discardbytes were in pqcomm.h, yet listed
as static in pqcomm.c -- but now made non-static)
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
Attachments:
proxy_protocol.patchtext/x-patch; charset=US-ASCII; name=proxy_protocol.patchDownload+411-19
Hi,
On Tue, 2 Mar 2021 at 14:43, Magnus Hagander <magnus@hagander.net> wrote:
PFA a simple patch that implements support for the PROXY protocol.
Nice. I didn't know I needed this. But in hindsight, I would've used
it quite a few times in the past if I could have.
The implementation adds a parameter named proxy_servers which lists
the ips or ip+cidr mask to be trusted. Since a proxy can decide what
the origin is, and this is used for security decisions, it's very
important to not just trust any server, only those that are
intentionally used. By default, no servers are listed, and thus the
protocol is disabled.
Might make sense to add special cases for 'samehost' and 'samenet', as
in hba rules, as proxy servers are commonly on the same machine or
share one of the same internal networks.
Despite the security issues, I'm sure people will soon try and set
proxy_servers='*' or 'all' if they think this setting works as
listen_addresses or as pg_hba. But I don't think I'd make these use
cases easier.
Tureba - Arthur Nascimento
On Tue, 2021-03-02 at 18:43 +0100, Magnus Hagander wrote:
PFA a simple patch that implements support for the PROXY protocol.
I'm not all the way through the patch yet, but this part jumped out at
me:
+ if (memcmp(proxyheader.sig, "\x0d\x0a\x0d\x0a\x00\x0d\x0a\x51\x55\x49\x54\x0a", sizeof(proxyheader.sig)) != 0) + { + /* + * Data is there but it wasn't a proxy header. Also fall through to + * normal processing + */ + pq_endmsgread(); + return STATUS_OK;
From my reading, the spec explicitly disallows this sort of fallback
behavior:
The receiver MUST be configured to only receive the protocol described in this
specification and MUST not try to guess whether the protocol header is present
or not. This means that the protocol explicitly prevents port sharing between
public and private access.
You might say, "if we already trust the proxy server, why should we
care?" but I think the point is that you want to catch
misconfigurations where the middlebox is forwarding bare TCP without
adding a PROXY header of its own, which will "work" for innocent
clients but in reality is a ticking timebomb. If you've decided to
trust an intermediary to use PROXY connections, then you must _only_
accept PROXY connections from that intermediary. Does that seem like a
reasonable interpretation?
--Jacob
On Wed, Mar 3, 2021 at 1:50 AM Jacob Champion <pchampion@vmware.com> wrote:
On Tue, 2021-03-02 at 18:43 +0100, Magnus Hagander wrote:
PFA a simple patch that implements support for the PROXY protocol.
I'm not all the way through the patch yet, but this part jumped out at
me:+ if (memcmp(proxyheader.sig, "\x0d\x0a\x0d\x0a\x00\x0d\x0a\x51\x55\x49\x54\x0a", sizeof(proxyheader.sig)) != 0) + { + /* + * Data is there but it wasn't a proxy header. Also fall through to + * normal processing + */ + pq_endmsgread(); + return STATUS_OK;From my reading, the spec explicitly disallows this sort of fallback
behavior:The receiver MUST be configured to only receive the protocol described in this
specification and MUST not try to guess whether the protocol header is present
or not. This means that the protocol explicitly prevents port sharing between
public and private access.You might say, "if we already trust the proxy server, why should we
care?" but I think the point is that you want to catch
misconfigurations where the middlebox is forwarding bare TCP without
adding a PROXY header of its own, which will "work" for innocent
clients but in reality is a ticking timebomb. If you've decided to
trust an intermediary to use PROXY connections, then you must _only_
accept PROXY connections from that intermediary. Does that seem like a
reasonable interpretation?
I definitely missed that part of the spec. Ugh.
That said, I'm not sure it's *actually* an issue in the case of
PostgreSQL. Given that doing what you're suggesting, accidentally
passing connections without PROXY, will get caught in pg_hba.conf.
That said, I agree with your interpretation, and it's pretty easy to
change it to that. Basically we just have to do the IP check *before*
doing the PROXY protocol check. It makes testing a bit more difficult
though, but maybe worth it?
I've attached a POC that does that. Note that I have *not* updated the docs!
Another option would of course be to listen on a separate port for it,
which seems to be the "haproxy way". That would be slightly more code
(we'd still want to keep the code for validating the list of trusted
proxies I'd say), but maybe worth doing?
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
Attachments:
proxy_protocol_only.patchtext/x-patch; charset=US-ASCII; name=proxy_protocol_only.patchDownload+392-19
On Wed, Mar 3, 2021 at 10:00 AM Magnus Hagander <magnus@hagander.net> wrote:
On Wed, Mar 3, 2021 at 1:50 AM Jacob Champion <pchampion@vmware.com> wrote:
On Tue, 2021-03-02 at 18:43 +0100, Magnus Hagander wrote:
PFA a simple patch that implements support for the PROXY protocol.
I'm not all the way through the patch yet, but this part jumped out at
me:+ if (memcmp(proxyheader.sig, "\x0d\x0a\x0d\x0a\x00\x0d\x0a\x51\x55\x49\x54\x0a", sizeof(proxyheader.sig)) != 0) + { + /* + * Data is there but it wasn't a proxy header. Also fall through to + * normal processing + */ + pq_endmsgread(); + return STATUS_OK;From my reading, the spec explicitly disallows this sort of fallback
behavior:The receiver MUST be configured to only receive the protocol described in this
specification and MUST not try to guess whether the protocol header is present
or not. This means that the protocol explicitly prevents port sharing between
public and private access.You might say, "if we already trust the proxy server, why should we
care?" but I think the point is that you want to catch
misconfigurations where the middlebox is forwarding bare TCP without
adding a PROXY header of its own, which will "work" for innocent
clients but in reality is a ticking timebomb. If you've decided to
trust an intermediary to use PROXY connections, then you must _only_
accept PROXY connections from that intermediary. Does that seem like a
reasonable interpretation?I definitely missed that part of the spec. Ugh.
That said, I'm not sure it's *actually* an issue in the case of
PostgreSQL. Given that doing what you're suggesting, accidentally
passing connections without PROXY, will get caught in pg_hba.conf.That said, I agree with your interpretation, and it's pretty easy to
change it to that. Basically we just have to do the IP check *before*
doing the PROXY protocol check. It makes testing a bit more difficult
though, but maybe worth it?I've attached a POC that does that. Note that I have *not* updated the docs!
Another option would of course be to listen on a separate port for it,
which seems to be the "haproxy way". That would be slightly more code
(we'd still want to keep the code for validating the list of trusted
proxies I'd say), but maybe worth doing?
In order to figure that out, I hacked up a poc on that. Once again
without updates to the docs, but shows approximately how much code
complexity it adds (not much).
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
Attachments:
proxy_protocol_separate_port.patchtext/x-patch; charset=US-ASCII; name=proxy_protocol_separate_port.patchDownload+450-25
+10 on this one!
Hosting a farm of read replicas and r/w endpoint behind an HAproxy makes
the powerful pg_hba purpose by hiding the real source address... which is
bad for some environments with strict conformance and audit requirements
Le mar. 2 mars 2021 à 12:43, Magnus Hagander <magnus@hagander.net> a écrit :
Show quoted text
PFA a simple patch that implements support for the PROXY protocol.
This is a protocol common and very light weight in proxies and load
balancers (haproxy is one common example, but also for example the AWS
cloud load balancers). Basically this protocol prefixes the normal
connection with a header and a specification of what the original host
was, allowing the server to unwrap that and get the correct client
address instead of just the proxy ip address. It is a one-way protocol
in that there is no response from the server, it's just purely a
prefix of the IP information.Using this when PostgreSQL is behind a proxy allows us to keep using
pg_hba.conf rules based on the original ip address, as well as track
the original address in log messages and pg_stat_activity etc.The implementation adds a parameter named proxy_servers which lists
the ips or ip+cidr mask to be trusted. Since a proxy can decide what
the origin is, and this is used for security decisions, it's very
important to not just trust any server, only those that are
intentionally used. By default, no servers are listed, and thus the
protocol is disabled.When specified, and the connection on the normal port has the proxy
prefix on it, and the connection comes in from one of the addresses
listed as valid proxy servers, we will replace the actual IP address
of the client with the one specified in the proxy packet.Currently there is no information about the proxy server in the
pg_stat_activity view, it's only available as a log message. But maybe
it should go in pg_stat_activity as well? Or in a separate
pg_stat_proxy view?(In passing, I note that pq_discardbytes were in pqcomm.h, yet listed
as static in pqcomm.c -- but now made non-static)--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
PFA a simple patch that implements support for the PROXY protocol.
This is a protocol common and very light weight in proxies and load
balancers (haproxy is one common example, but also for example the AWS
cloud load balancers). Basically this protocol prefixes the normal
connection with a header and a specification of what the original host
was, allowing the server to unwrap that and get the correct client
address instead of just the proxy ip address. It is a one-way protocol
in that there is no response from the server, it's just purely a
prefix of the IP information.
Is there any formal specification for the "a protocol common and very
light weight in proxies"? I am asking because I was expecting that is
explained in your patch (hopefully in "Frontend/Backend Protocol"
chapter) but I couldn't find it in your patch.
Also we need a regression test for this feature.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
On Thu, 2021-03-04 at 10:42 +0900, Tatsuo Ishii wrote:
Is there any formal specification for the "a protocol common and very
light weight in proxies"?
See
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
which is maintained by HAProxy Technologies.
--Jacob
On Wed, 2021-03-03 at 10:39 +0100, Magnus Hagander wrote:
On Wed, Mar 3, 2021 at 10:00 AM Magnus Hagander <magnus@hagander.net> wrote:
Another option would of course be to listen on a separate port for it,
which seems to be the "haproxy way". That would be slightly more code
(we'd still want to keep the code for validating the list of trusted
proxies I'd say), but maybe worth doing?In order to figure that out, I hacked up a poc on that. Once again
without updates to the docs, but shows approximately how much code
complexity it adds (not much).
From a configuration perspective, I like that the separate-port
approach can shift the burden of verifying trust to an external
firewall, and that it seems to match the behavior of other major server
software. But I don't have any insight into the relative security of
the two options in practice; hopefully someone else can chime in.
memset((char *) &hints, 0, sizeof(hints));
hints.ai_flags = AI_NUMERICHOST;
hints.ai_family = AF_UNSPEC;ret = pg_getaddrinfo_all(tok, NULL, &hints, &gai_result);
Idle thought I had while setting up a local test rig: Are there any
compelling cases for allowing PROXY packets to arrive over Unix
sockets? (By which I mean, the proxy is running on the same machine as
Postgres, and connects to it using the .s.PGSQL socket file instead of
TCP.) Are there cases where you want some other software to interact
with the TCP stack instead of Postgres, but it'd still be nice to have
the original connection information available?
--Jacob
On 3/4/21 2:45 PM, Jacob Champion wrote:
On Thu, 2021-03-04 at 10:42 +0900, Tatsuo Ishii wrote:
Is there any formal specification for the "a protocol common and very
light weight in proxies"?See
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
which is maintained by HAProxy Technologies.
--Jacob
This looks like it would only need a few extra protocol messages to be
understood by the backend. It might be possible to implement that with
the loadable wire protocol extensions proposed here:
https://commitfest.postgresql.org/32/3018/
Regards, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
On Thu, Mar 4, 2021 at 9:29 PM Jan Wieck <jan@wi3ck.info> wrote:
On 3/4/21 2:45 PM, Jacob Champion wrote:
On Thu, 2021-03-04 at 10:42 +0900, Tatsuo Ishii wrote:
Is there any formal specification for the "a protocol common and very
light weight in proxies"?See
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
which is maintained by HAProxy Technologies.
--Jacob
This looks like it would only need a few extra protocol messages to be
understood by the backend. It might be possible to implement that with
the loadable wire protocol extensions proposed here:
Actually the whole point of it is that it *doesn't* need any new
protocol messages. And that it *wraps* whatever is there, definitely
doesn't replace it. It should equally be wrapping whatever an
extension uses.
So while the base topic is not unrelated, I don't think there is any
overlap between these.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
On Thu, Mar 4, 2021 at 9:07 PM Jacob Champion <pchampion@vmware.com> wrote:
On Wed, 2021-03-03 at 10:39 +0100, Magnus Hagander wrote:
On Wed, Mar 3, 2021 at 10:00 AM Magnus Hagander <magnus@hagander.net> wrote:
Another option would of course be to listen on a separate port for it,
which seems to be the "haproxy way". That would be slightly more code
(we'd still want to keep the code for validating the list of trusted
proxies I'd say), but maybe worth doing?In order to figure that out, I hacked up a poc on that. Once again
without updates to the docs, but shows approximately how much code
complexity it adds (not much).From a configuration perspective, I like that the separate-port
approach can shift the burden of verifying trust to an external
firewall, and that it seems to match the behavior of other major server
software. But I don't have any insight into the relative security of
the two options in practice; hopefully someone else can chime in.
Yeah I think that and the argument that the spec explicitly says it
should be on it's own port is the advantage. The disadvantage is,
well, more ports and more configuration. But it does definitely make a
more clean separation of concerns.
memset((char *) &hints, 0, sizeof(hints));
hints.ai_flags = AI_NUMERICHOST;
hints.ai_family = AF_UNSPEC;ret = pg_getaddrinfo_all(tok, NULL, &hints, &gai_result);
Idle thought I had while setting up a local test rig: Are there any
compelling cases for allowing PROXY packets to arrive over Unix
sockets? (By which I mean, the proxy is running on the same machine as
Postgres, and connects to it using the .s.PGSQL socket file instead of
TCP.) Are there cases where you want some other software to interact
with the TCP stack instead of Postgres, but it'd still be nice to have
the original connection information available?
I'm uncertain what that usecase would be for something like haproxy,
tbh. It can't do connection pooling, so adding it on the same machine
as postgres itself wouldn't really add anything, I think?
Iid think about the other end, if you had a proxy on a different
machine accepting unix connections and passing them on over
PROXY-over-tcp. But I doubt it's useful to know it was unix in that
case (since it still couldn't do peer or such for the auth) --
instead, that seems like an argument where it'd be better to proxy
without using PROXY and just letting the IP address be.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
On Thu, Mar 4, 2021 at 8:45 PM Jacob Champion <pchampion@vmware.com> wrote:
On Thu, 2021-03-04 at 10:42 +0900, Tatsuo Ishii wrote:
Is there any formal specification for the "a protocol common and very
light weight in proxies"?See
Yeah, it's currently in one of the comments, but should probably be
added to the docs side as well.
And yes tests :) Probably not a regression test, but some level of tap
testing should definitely be added. We'll just have to find a way to
do that without making haproxy a dependency to run the tests :)
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
On 3/4/21 3:40 PM, Magnus Hagander wrote:
On Thu, Mar 4, 2021 at 9:29 PM Jan Wieck <jan@wi3ck.info> wrote:
This looks like it would only need a few extra protocol messages to be
understood by the backend. It might be possible to implement that with
the loadable wire protocol extensions proposed here:Actually the whole point of it is that it *doesn't* need any new
protocol messages. And that it *wraps* whatever is there, definitely
doesn't replace it. It should equally be wrapping whatever an
extension uses.So while the base topic is not unrelated, I don't think there is any
overlap between these.
I might be missing something here, but isn't sending some extra,
informational *header*, which is understood by the backend, in essence a
protocol extension?
Regards, Jan
--
Jan Wieck
Principle Database Engineer
Amazon Web Services
On Thu, Mar 4, 2021 at 10:01 PM Jan Wieck <jan@wi3ck.info> wrote:
On 3/4/21 3:40 PM, Magnus Hagander wrote:
On Thu, Mar 4, 2021 at 9:29 PM Jan Wieck <jan@wi3ck.info> wrote:
This looks like it would only need a few extra protocol messages to be
understood by the backend. It might be possible to implement that with
the loadable wire protocol extensions proposed here:Actually the whole point of it is that it *doesn't* need any new
protocol messages. And that it *wraps* whatever is there, definitely
doesn't replace it. It should equally be wrapping whatever an
extension uses.So while the base topic is not unrelated, I don't think there is any
overlap between these.I might be missing something here, but isn't sending some extra,
informational *header*, which is understood by the backend, in essence a
protocol extension?
Bad choice of words, I guess.
The points being, there is a single packet sent ahead of the normal
stream. There are no new messages in "the postgresql protocol" or "the
febe protocol" or whatever we call it. And it doesn't change the
properties of any part of that protocol. And, importantly for the
simplicity, there is no negotiation and there are no packets going the
other way.
But sure, you can call it a protocol extension if you want. And yes,
it could probably be built on top of part of the ideas in that other
patch, but most of it would be useless (the abstraction of the listen
functionality into listen_have_free_slot/listen_add_socket would be
the big thing that could be used)
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
On Thu, 2021-03-04 at 10:42 +0900, Tatsuo Ishii wrote:
Is there any formal specification for the "a protocol common and very
light weight in proxies"?See
Yeah, it's currently in one of the comments, but should probably be
added to the docs side as well.
It seems the protocol is HAproxy product specific and I think it would
be better to be mentioned in the docs.
And yes tests :) Probably not a regression test, but some level of tap
testing should definitely be added. We'll just have to find a way to
do that without making haproxy a dependency to run the tests :)
Agreed.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
On Thu, 2021-03-04 at 21:45 +0100, Magnus Hagander wrote:
On Thu, Mar 4, 2021 at 9:07 PM Jacob Champion <pchampion@vmware.com> wrote:
Idle thought I had while setting up a local test rig: Are there any
compelling cases for allowing PROXY packets to arrive over Unix
sockets? (By which I mean, the proxy is running on the same machine as
Postgres, and connects to it using the .s.PGSQL socket file instead of
TCP.) Are there cases where you want some other software to interact
with the TCP stack instead of Postgres, but it'd still be nice to have
the original connection information available?I'm uncertain what that usecase would be for something like haproxy,
tbh. It can't do connection pooling, so adding it on the same machine
as postgres itself wouldn't really add anything, I think?
Yeah, I wasn't thinking HAproxy so much as some unspecified software
appliance that's performing Some Task before allowing a TCP client to
speak to Postgres. But it'd be better to hear from someone that has an
actual use case, instead of me spitballing.
Iid think about the other end, if you had a proxy on a different
machine accepting unix connections and passing them on over
PROXY-over-tcp. But I doubt it's useful to know it was unix in that
case (since it still couldn't do peer or such for the auth) --
instead, that seems like an argument where it'd be better to proxy
without using PROXY and just letting the IP address be.
You could potentially design a system that lets you proxy a "local all
all trust" setup from a different (trusted) machine, without having to
actually let people onto the machine that's running Postgres. That
would require some additional authentication on the PROXY connection
(i.e. something stronger than host-based auth) to actually be useful.
-- other notes --
A small nitpick on the current separate-port PoC is that I'm forced to
set up a "regular" TCP port, even if I only want the PROXY behavior.
The original-host logging isn't working for me:
WARNING: pg_getnameinfo_all() failed: ai_family not supported
LOG: proxy connection from: host=??? port=???
and I think the culprit is this:
/* Store a copy of the original address, for logging */
memcpy(&raddr_save, &port->raddr, port->raddr.salen);
port->raddr.salen is the length of port->raddr.addr; we want the length
of the copy to be sizeof(port->raddr) here, no?
--Jacob
The current proposal seems to miss the case of transaction pooling
(and statement pooling) where the same established connection
multiplexes transactions / statements from multiple remote clients.
What we would need for that case would be a functionl
pg_set_remote_client_address( be_key, remote_ip, remote_hostname)
where only be_key and remote_ip are required, but any string (up to a
certain length) would be accepted as hostname.
It would be really nice if we could send this request at protocol level but
if that is hard to do then having a function would get us half way there.
the be_key in the function is the key from PGcancel, which is stored
by libpq when making the connection, and it is there, to make sure
that only the directly connecting proxy can successfully call the function.
Cheers
Hannu
Show quoted text
On Fri, Mar 5, 2021 at 12:21 AM Jacob Champion <pchampion@vmware.com> wrote:
On Thu, 2021-03-04 at 21:45 +0100, Magnus Hagander wrote:
On Thu, Mar 4, 2021 at 9:07 PM Jacob Champion <pchampion@vmware.com> wrote:
Idle thought I had while setting up a local test rig: Are there any
compelling cases for allowing PROXY packets to arrive over Unix
sockets? (By which I mean, the proxy is running on the same machine as
Postgres, and connects to it using the .s.PGSQL socket file instead of
TCP.) Are there cases where you want some other software to interact
with the TCP stack instead of Postgres, but it'd still be nice to have
the original connection information available?I'm uncertain what that usecase would be for something like haproxy,
tbh. It can't do connection pooling, so adding it on the same machine
as postgres itself wouldn't really add anything, I think?Yeah, I wasn't thinking HAproxy so much as some unspecified software
appliance that's performing Some Task before allowing a TCP client to
speak to Postgres. But it'd be better to hear from someone that has an
actual use case, instead of me spitballing.Iid think about the other end, if you had a proxy on a different
machine accepting unix connections and passing them on over
PROXY-over-tcp. But I doubt it's useful to know it was unix in that
case (since it still couldn't do peer or such for the auth) --
instead, that seems like an argument where it'd be better to proxy
without using PROXY and just letting the IP address be.You could potentially design a system that lets you proxy a "local all
all trust" setup from a different (trusted) machine, without having to
actually let people onto the machine that's running Postgres. That
would require some additional authentication on the PROXY connection
(i.e. something stronger than host-based auth) to actually be useful.-- other notes --
A small nitpick on the current separate-port PoC is that I'm forced to
set up a "regular" TCP port, even if I only want the PROXY behavior.The original-host logging isn't working for me:
WARNING: pg_getnameinfo_all() failed: ai_family not supported
LOG: proxy connection from: host=??? port=???and I think the culprit is this:
/* Store a copy of the original address, for logging */
memcpy(&raddr_save, &port->raddr, port->raddr.salen);port->raddr.salen is the length of port->raddr.addr; we want the length
of the copy to be sizeof(port->raddr) here, no?--Jacob
On 5/3/21 0:21, Jacob Champion wrote:
On Thu, 2021-03-04 at 21:45 +0100, Magnus Hagander wrote:
On Thu, Mar 4, 2021 at 9:07 PM Jacob Champion <pchampion@vmware.com> wrote:
Idle thought I had while setting up a local test rig: Are there any
compelling cases for allowing PROXY packets to arrive over Unix
sockets? (By which I mean, the proxy is running on the same machine as
Postgres, and connects to it using the .s.PGSQL socket file instead of
TCP.) Are there cases where you want some other software to interact
with the TCP stack instead of Postgres, but it'd still be nice to have
the original connection information available?I'm uncertain what that usecase would be for something like haproxy,
tbh. It can't do connection pooling, so adding it on the same machine
as postgres itself wouldn't really add anything, I think?Yeah, I wasn't thinking HAproxy so much as some unspecified software
appliance that's performing Some Task before allowing a TCP client to
speak to Postgres. But it'd be better to hear from someone that has an
actual use case, instead of me spitballing.
Here's a use case: Envoy's Postgres filter (see [1]https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/postgres_proxy_filter, [2]https://www.cncf.io/blog/2020/08/13/envoy-1-15-introduces-a-new-postgres-extension-with-monitoring-support/). Right now
is able to capture protocol-level metrics and send them to a metrics
collector (eg. Prometheus) while proxying the traffic. More capabilities
are being added as of today, and will eventually manage HBA too. It
would greatly benefit from this proposal, since it proxies the traffic
with, obviously, its IP, not the client's. It may be used (we do)
locally fronting Postgres, via UDS (so it can be easily trusted).
Álvaro
[1]: https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/postgres_proxy_filter
https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/postgres_proxy_filter
[2]: https://www.cncf.io/blog/2020/08/13/envoy-1-15-introduces-a-new-postgres-extension-with-monitoring-support/
https://www.cncf.io/blog/2020/08/13/envoy-1-15-introduces-a-new-postgres-extension-with-monitoring-support/
--
Alvaro Hernandez
-----------
OnGres
On Fri, Mar 5, 2021 at 12:57 AM Hannu Krosing <hannuk@google.com> wrote:
The current proposal seems to miss the case of transaction pooling
(and statement pooling) where the same established connection
multiplexes transactions / statements from multiple remote clients.
Not at all.
The current proposal is there to implement the PROXY protocol. It
doesn't try to do anything with connection pooling at all.
Solving a similar problem for connection poolers would also definitely
be a useful thing, but it is entirely out of scope of this patch, and
is a completely separate implementation.
I'd definitely like to see that one solved as well, but let's look at
it on a different thread so we don't derail this one.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
