> So what I propose is that we authorize the proxy like a normal client > against AuthAction consume/produce/admin. In other words, if a client has a > roleToken which is Authorized to produce but the Proxy roleToken doesn't > have AuthAction produce on it - then the request is denied.
I see, so instead of requiring "super-user" permission for the proxy, you propose to only require access to the specific topic being proxied. Sounds good and seems to be very flexible. One can still add the proxy as the "super-user" and whitelist it to access all topics or choose the fine-grained approach. >1. Current auth flow - as implemented in this PR > [image: Inline image 1] Image didn't make it on the email > Code Change:- The proxy should send the client certificate to the broker > ? and the broker should authorize and authenticate the client as well as > the proxy. In some cases the authentication cannot be easily done again in the broker, for example if that needs to validate the IP of the client. > b. The broker should be able to distinguish between a proxy and a client so that no compromised proxy can impersonate a client. > Code Change:- add proxyRole as a config param like we do for superUserRole and enforce that originalPrinciple is passed when proxy tries to connect. I'm not fully understanding how adding the "proxyRole" can prevent a compromised proxy to impersonate a client. Cannot a proxy just vouch for itself? Or do you mean that along with change (a) (passing the original certificate) that should prevent it? On Fri, Jan 19, 2018 at 4:05 PM Jai Asher <jai.ashe...@gmail.com> wrote: > Hi, > We had a small discussion about this solution (internally) - > publishing the minutes and action items so that remaining pulsar devs can > chime in. > > 1. Current auth flow - as implemented in this PR > [image: Inline image 1] > > > 2. Maurice had pointed out some further enhancements we can > incorporate:- > a. Proxy extracting the roleToken and broker just authorizing this > roletoken is not a very secure model (kind of what we discussed earlier > here <https://github.com/apache/incubator-pulsar/issues/858>). One point > that he added to our initial discussion was that a roleToken (string) is > modifiable but a certificated is not - since it is signed, > Code Change:- The proxy should send the client certificate to the > broker and the broker should authorize and authenticate the client as well > as the proxy. > > b. The broker should be able to distinguish between a proxy and a > client so that no compromised proxy can impersonate a client. > Code Change:- add proxyRole as a config param like we do for > superUserRole and enforce that originalPrinciple is passed when proxy tries > to connect. > > As Rajan had suggested I will create a *separate* PR to address > Maurice's enhancements on top of the current implementation so that we can > make incremental progress. > > 3. Since this is an open source project I will make the flow as > customizable and components as pluggable as possible. > > Thanks to Rajan, Andrews, Maurice and Joe for the inputs. > > Regards, > Jai > > On Tue, Jan 2, 2018 at 12:04 PM, Jai Asher <jai.ashe...@gmail.com> wrote: > >> Hi all, >> I've created PIP for Adding more Security checks to Pulsar Proxy. >> High-level description: >> * The machine hosting the Pulsar proxy will have a public IP and >> susceptible to all kinds of web attacks. The aim of this PIP is to minimize >> the damage caused by a compromised proxy on the entire service.* >> >> PIP:- >> https://github.com/apache/incubator-pulsar/wiki/PIP-9:-Adding-more-Security-checks-to-Pulsar-Proxy >> > PR:- https://github.com/apache/incubator-pulsar/pull/1002 >> Issue:- https://github.com/apache/incubator-pulsar/issues/858 >> >> Can you please review and provide your feedback/comments. >> >> Regards, >> Jai >> > -- Matteo Merli <mme...@apache.org>
