Hi Matteo, > Image didn't make it on the email
Sorry for that - here is the link to the image https://drive.google.com/file/d/1j6ElXghUwwlr6YqUClp-Nx5sBFOW8sfi/view?usp=sharing > 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. Agreed so I will make sending roleToken/actual cert optional on the client side and also have a flag on broker side to enforce this ( that the proxy has sent certificate and not just a roleToken). Flag name authenticateProxyClient=true > 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? I don't fully understand the question but the attack I was talking about is that once a proxy host is compromised it can choose to send originalPrincipal as null which will make the broker treat it as a normal client and authenticate/authorize the proxy as a normal client rather than demanding to authorize the originalPrincipal. So for example:- A client using topic T1 with roleToken R1 going through proxy with roleToken R3 will require granting AuthAction produce/consume on both R1 and R3 (proxy). Similarly, a client using topic T2 with roleToken R2 going through the same proxy will require granting AuthAction produce/consume on both R1 and R3 (proxy). Now with my current PR if proxy is compromised it can access topics T1 and T2 without requiring client roleToken (R1 and R2) at all by passing originalPrincipal as null. If I add a broker side setting "proxyRoles=R3, R4", then as soon as I see that the roleToken (R3) extracted from the incoming cert is in proxyRoles (R3, R4) then I can return an error if originalPrincipal is null. Regards, Jai On Fri, Jan 19, 2018 at 4:20 PM, Matteo Merli <matteo.me...@gmail.com> wrote: > > 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> >
