This message was deleted.

it's because of how the Pulsar binary protocol works. Each broker must be addressable directly from clients. That's what the Pulsar Proxy provides. There are also other alternatives such as general SNI proxy usage (for example Apache Traffic Server, ATS), described at https://pulsar.apache.org/docs/3.1.x/concepts-proxy-sni-routing/ .

Thanks @Lari Hotari!

If there's a way to avoid using the Pulsar Proxy, that's actually the recommended way to go. Pulsar Proxy can be avoided with private networking configurations where routing from the clients to brokers is configured.

The private network option is not available for me unfortunately. We need make this work over the internet. I am now able to handle authentication on proxy and authorization on the broker.

please check the Pulsar Proxy documentation about the security design:

The Pulsar proxy is not intended to be exposed on the public internet. The security considerations in the current design expect network perimeter security. The requirement of network perimeter security can be achieved with private networks.

If a proxy deployment cannot be protected with network perimeter security, the alternative would be to use Pulsar's "Proxy SNI routing" feature with a properly secured and audited solution. In that case Pulsar proxy component is not used at all.

https://pulsar.apache.org/docs/3.1.x/administration-proxy/ This is perhaps a surprise for many since Pulsar Helm charts do expose the proxies on the public internet by default.

Shouldn't it be OK to expose Pulsar Proxy as long as we add authentication to it?

The original design expects network perimeter security. For example, Pulsar Proxy doesn't have DoS attack protection which could be considered as a mandatory feature when something is exposed directly on public internet.

While handling that CVE-2022-24280 https://github.com/apache/pulsar/wiki/CVE-2022-24280, we added the clarification to the documentation.

This sounds like we can avoid having the Pulsar Proxy being vulnerable to DDoS attacks. I've looked into SNI routing docs now and it left me confused. This part more specifically:

The proxy in Pulsar acts as a reverse proxy, and creates a gateway in front of brokers. Proxies such as Apache Traffic Server (ATS), HAProxy, Nginx, and Envoy are not supported in Pulsar. These proxy-servers support SNI routing.

Does this mean that we can either use Pulsar Proxy normally or one of the other reverse proxies listed by using SNI routing? IIUC in the SNI routing scenario, we'd only add authentication in the broker itself.

> I've looked into SNI routing docs now and it left me confused. This part more specifically: Yes, that is confusing and doesn't make sense. > Does this mean that we can either use Pulsar Proxy normally or one of the other reverse proxies listed by using SNI routing? IIUC in the SNI routing scenario, we'd only add authentication in the broker itself. For the SNI routing option, Pulsar Proxy is not used at all. The SNI routing proxy, such as Apache Traffic Server, will act as the proxy between clients and the Pulsar brokers. One important detail from the security perspective is that TLS isn't terminated in SNI routing. It's end-to-end TLS from the clients to the brokers. Yes, authentication is handled in the brokers. When using a SNI routing proxy, you would have to deal with the security of that component. You don't want anyone from the public internet to be able to knock on the broker's door via the SNI routing proxy.

Thank you very much @Lari Hotari , this helps a lot. I will have a look into the issue you've created as well and try to contribute.

the docs for the advertised listeners part is at https://pulsar.apache.org/docs/3.1.x/concepts-multiple-advertised-listeners/ . I believe that it's necessary to use that in combination with SNI routing.