We have a few questions on using Presto with a Cloudera cluster with Sentry in place:
Please see my response inlined.
Presto works with Sentry established in the environment, but just bypasses all the security checks, right? i.e. it makes no difference to Presto whether sentry is in place or not
Yes, Presto will bypass Sentry's security checks.
They’ve said Cloudera removed SQL standard authorization in Hive in favor of Sentry. Does that mean Presto cannot use the sql-standard authorization model for the hive connector? (this appears to suggest it cannot - https://groups.google.com/forum/#!topic/presto-users/OwsBtVw10jY). If it can’t, do we know what other customers have done to accommodate this?
With Sentry in place, SQL standard authorization might fail. We don't support Sentry authorization, and haven't done any testing, so I am not sure of the behavior or other workarounds.
Is there a way to enforce column-level security in Presto accessing CDH? It could be accomplished with a combination of many many views and sql-standard auth, but is there a more admin and user friendly way to go about this? Is this doable via a SystemAccessControl implementation?
- They’re used to Sentry where you can run “GRANT SELECT(column_name) ON TABLE table_name TO ROLE role_name;”
Presto doesn't have column-level access control checks yet. Also, since the SystemAccessControl interface in SPI has not introduced column level security checks, I don't think this can be achieved via a SystemAccessControl implementation, without modifying the SPI. So I don't see a user friendly way to go about this.