PostgreSQL filter – require downstream TLS

[wasd171]

Allow to configure downstream_ssl similar to upstream_ssl for envoy.filters.network.postgres_proxy

Description:
Currently envoy.filters.network.postgres_proxy allows to configure TLS mode for the upstream connection (DISABLE / REQUIRE). With Envoy deployed at the edge as a PostgreSQL proxy, it is often needed to force incoming outside connections to use TLS, which is not possible now. Another use case could be with projects that provide PostgreSQL-compatible API but do not implement encryption – in this case Envoy could be used as a sidecar requiring TLS.

Proposal:
With an additional downstream_ssl setting it should be possible to configure TLS requirements for the downstream traffic. The following values could be supported:

1. REQUIRE – Envoy will drop downstream connections that refuse to upgrade to TLS
2. ALLOW – this is current behaviour, Envoy would use TLS if the downstream supports it (and it is configured at the filter level), but otherwise would also work with unencrypted connection. This could be a default setting
3. DISABLE – Envoy would force all downstream connections to be unencrypted

@cpakulski what would you say about this proposal?

[cpakulski]

I think that this proposal makes sense. That would require new API item and previous method of configuring downstream ssl must be supported for backwards compatibility for some time.

[wasd171]

Adding new downstream_ssl setting should play well with the existing terminate_ssl configuration since terminate_ssl does not impose any requirements for the downstream connection

Docs say that

If the filter does not manage to terminate the SSL session, it will close the connection from the client

However, I was able to connect to a SSL terminating (terminate_ssl: true) Envoy PostgreSQL proxy with sslmode=disable – is it intentional?

If yes, then the downstream_ssl could perfectly work together with the terminate_ssl option, given that the ALLOW option is a default one, because it replicates the current behaviour. It is a bit unclear how downstream_ssl: DISABLE option would work with terminate_ssl: true since they contradict each other, but given that this would not be a default choice, I think it would be fine for the downstream_ssl to take a preference and reject SSL connections from the downstream

[cpakulski]

However, I was able to connect to a SSL terminating (terminate_ssl: true) Envoy PostgreSQL proxy with sslmode=disable – is it intentional?

The design principle was to allow SSL if it comes, not to enforce it, so it is very probable that cleartext also works with terminate_ssl enabled.

Thanks like a nice proposal. Thanks for describing it here.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.