I think stale state is a big problem with caches of sentry state in general. What we need to have is some way of following a stream of events...
best, Colin On Fri, May 27, 2016, at 13:22, Gregory Chanan wrote: > Hi Bhooshan, > > Take a look at SENTRY-1229. It's only supported for the generic service > and it makes multiple calls and there's no callback mechanism. But it's > a > start. > > Greg > > On Mon, May 23, 2016 at 4:53 PM, Bhooshan Mogal > <[email protected]> > wrote: > > > Hi folks, > > > > I have a product where I want to use Sentry to authorize read requests. > > However, since read performance is key, I do not want to make a call to > > Sentry for every read request, and would like to have some sort of a cache. > > A cache is tricky, especially in the security context, because it needs to > > be consistent with the Sentry service at all times, especially when > > privileges are revoked, so there are no security loopholes. > > > > So, I have a couple of questions: > > 1. Doest Sentry Service make a snapshot of all the data it fronts > > available? > > 2. Is there a callback mechanism in Sentry when an ACL is updated e.g. some > > permissions are revoked? > > > > I took a look at the AuthorizationPolicy in Impala, which manages a cache, > > but (correct me if I'm wrong), it seems like building that cache involves > > multiple calls to the Sentry Service. This process may take a while, and > > will suffer from stale data, as documented at > > > > https://github.com/cloudera/recordservice/blob/master/fe/src/main/java/com/cloudera/impala/util/SentryProxy.java#L85-L95 > > . > > > > Thanks in advance, > > -- > > Bhooshan > >
