I have updated the Wiki page with a section about TLS : https://github.com/apache/incubator-pulsar/wiki/PIP-1#tls-encryption-and-authentication
Also, I just posted a PR with the implementation: https://github.com/apache/incubator-pulsar/pull/548 -- Matteo Merli <matteo.me...@gmail.com> On Fri, Jun 30, 2017 at 5:09 PM, Dave Fisher <dave2w...@comcast.net> wrote: > > > On Jun 30, 2017, at 4:39 PM, Matteo Merli <matteo.me...@gmail.com> > wrote: > > > > On Fri, Jun 30, 2017 at 12:41 PM, Dave Fisher <dave2w...@comcast.net> > wrote: > > > >> So I am clear the problem is having an SSL endpoint that authenticates > the > >> client and allows the messages to flow through to the correct broker. > >> > > > > > > The main problem this proposal is trying to solve is how to expose > Pulsar, > > which is a stateful service [1], through a stateless frontend. > > One thought is make the proxy into a WebSocket frontend but then pass > through to the broker using the TCP protocol. > > WebSocket would fit a pattern that everyone is used to scaling. It could > be setup through Tomcat with connections through a VIP. > > Think about it. > > > The reason to have a stateless frontend, is that it's much easier to give > > access to this service from outside the current cluster/datacenter. If > you > > have a stateless service, you can easily use multiple strategies (VIP, > DNS, > > ....) to expose multiple instances that are composing the service and you > > don't need to connect to specific nodes. Any node, as routed by the > > VIP/DNS/.. mechanism will work. > > > > One example of this is when deploying in a cloud environment, especially > > with some container orchestration mechanism like kubernetes. If you want > to > > connect and publish messages from outside the Kubernetes cluster (or from > > outside the cloud region alltogether), having the stateless service, > > exposed to a cloud specific load balancer, makes it a lot easier to > deploy > > and to control the access from the outside world. > > Yes and this could work with WebSocket. > > > > > For the SSL part, right now in Pulsar you might want to use TLS/SSL for > few > > reasons: > > 1. Transport encryption > > 2. Broker authentication (validate the broker we're talking to is > > legitimate) > > 3. Client authentication (extract the client principal to be used for > > authorization) > > > > All these 3 should continue to work even when a proxy is introduced. In > > particular, for the client authentication, the proxy is responsible of > > validating the authentication and then carry the client principal over to > > the broker. > > > > > >>> Can I assume that if the broker disconnects that the requirement is for > > the client to reconnect and then at that point get the new broker? > > > > Correct, that's the behavior of the client library and it will not > change. > > Whenever the connection breaks, the client library internally tries to > > re-do the topic lookup (because now it might have moved to a different > > broker) and reconnect, with exponential backoff, until it succeeds. > > > > > > [1] brokers don't keep state on disk, but still a topic is only assign > to > > a single broker at a give point in time. > > > > Great. > > Regards, > Dave > > > > > -- > > Matteo Merli > > <matteo.me...@gmail.com> > >
