On Wed, Jan 9, 2019 at 8:24 AM Ivan Kelly <iv...@apache.org> wrote: > This could be sidestepped by having a rest endpoint to ask whether > role R has access to resource X. > > In fact, it looks like if you give the proxy access to ZK, then ZK can > be dos'd via the proxy. >
The ACLs are cached locally though (and watches are used to refresh the cache) so that shouldn’t be a problem. > -Ivan > > On Wed, Jan 9, 2019 at 4:32 PM Jai Asher <jai.ashe...@gmail.com> wrote: > > > > Ideally, it's better if we can authorize at proxy level and reject all > > unauthorized connections before connecting to the broker - lesser chances > > of broker being Dos’d. However in order to authorize a role, we needed > > access to zookeeper, connection to zookeeper was something we wanted to > > avoid for proxy since it is on a public IP - hence we authenticate at > proxy > > level and authorize at the broker, but that’s not the ideal > configuration. > > > > On Wed, Jan 9, 2019 at 3:10 AM Ivan Kelly <iv...@apache.org> wrote: > > > > > > Assume a role/principal R has permissions to produce on a > namespace. > > > If > > > > we don't authenticate at the proxy then anyone (attacker) can say > that > > > they > > > > belong to role R and connect to the proxy, the proxy will forward the > > > role > > > > name to the broker which will authorize it and allow access. > Instead, we > > > > need to *authenticate* at the proxy and reject all connections which > are > > > > trying to falsify their credentials and then the broker will reject > all > > > > roles/principal which are not *authorized* to access the namespace. > > > > > > Well, yes, that's what I would expect to happen. So what is the point > > > of have auth*ORIZATION* in the proxy? If the broker is going to apply > > > the authorization anyhow, shouldn't we do authentication at the proxy > > > level? > > > > > > -Ivan > > > > -- Matteo Merli <mme...@apache.org>
