The idea looks interesting. So, we have the following hooks or plugins in HMS for dealing with authorization:
- A MetastoreAuthzBinding hook which enforces HMS authorization. - A SentryJSONMessageFactory which works with DbNotificationListener to generate correct event messages. - A SentryHMSSyncPostEventListener to let the Sentry server know about a new update on HMS. - And of course, the use of HMS notifications to have metadata sync with HMS. Enforcing authorization through the proxy instead of the MetastoreAuthzBinding is the same. HMS currently calls a firePreEvent() to check for authorization. Having a proxy would be similar but it will have to know which API methods require authorization, "create_table, create_database, ...". A proxy does not inherit nor implement those methods, so what if a new API method in HMS is added? The proxy won't handle it until we manually detected the new API on the HMS, right? Sync HMS metadata with Sentry through the proxy instead of fetching HMS notifications would have the complication that if a create_table() transaction is committed but an error happens in the proxy when connecting to Sentry to notify about such event, then that event will be missed in Sentry, right? Or am I missing something about the proxy idea? - On Mon, Mar 5, 2018 at 11:45 PM, Alexander Kolbasov <ak...@cloudera.com> wrote: > I was thinking about possible alternatives to the way Sentry works with > HMS. What do people think of Sentry being a proxy to HMS thrift protocol? > This way it can see all HMS requests and responses and can enforce > HMS-level privileges without any plugins (Hiveserver2 still needs plugins) > and it wouldn't need HMS notifications to know what is going on. > > What do you think about it? > > - Alex >
