Thanks for bringing this up Bhooshan! Apache Sentry does not support delegation tokens yet. Looking at your use case, it seems like cache with strong (near strong) freshness guarantees is the key requirement here. Sentry does plan to support a way to store delta changes and serve these deltas through API in future. That would make it easier for the downstream clients who wish to cache (read only) the permission data to have an efficient and reliable way to keep the cache upto date.
Having said that, curious how does your master cache the permissions today? And is the latency of multiple RPC in your proposed approach acceptable: Container -> this new service -> Sentry service using delegation token? And how is this approach better than just making an RPC to Sentry directly? Also, I am sure community would benefit greatly from your Sentry use case. Would you be interested in blogging about it on Apache blog? On Wed, Aug 3, 2016 at 8:49 AM, Bhooshan Mogal <bhooshan.mo...@gmail.com> wrote: > Hi Folks, > > Any thoughts? > > - > Bhooshan > > On Sat, Jul 30, 2016 at 8:33 AM, Bhooshan Mogal <bhooshan.mo...@gmail.com> > wrote: > > > Hi, > > > > Does the Sentry Service provide delegation tokens for processes without > > Kerberos credentials to communicate with it (from YARN containers). > > > > > > Use case: We have programs running in YARN accessing some entities on > whom > > authorization is enforced using Apache Sentry. There is a master process > > that can communicate with Sentry just fine using its Kerberos > credentials. > > We have some level of caching implemented for ACLs as well, so we don't > > have to hit Sentry for every authorization request. However, given that > > this is a security feature, the cache needs to be updated very > frequently. > > For updating this cache, going via the master every single time will > create > > a bottleneck. So we wanted to explore if there was a way if a dedicated > > service running in YARN containers (not every program, but a dedicated > > service) can communicate with Sentry using delegation tokens. Exposing > the > > master's kerberos credentials to such a service is not an option because > it > > would lead to a security loophole. > > > > This would be similar to what KMS offers via > > https://issues.apache.org/jira/browse/HADOOP-10769. > > > > > > Thanks in advance, > > Bhooshan > > > > > > > -- > Bhooshan > -- Sravya Tirukkovalur
