Apache Ranger

Apache Ranger models tabular objects are stored in a Kudu cluster in the following hierarchy: Database, Table, Column.

Database: Kudu does not have the concept of a database. Therefore, a database is indicated as a prefix of table names with the format <database>.<table>. Since Kudu's only restriction on table names is that they be valid UTF-8 encoded strings, Kudu considers special characters to be valid parts of database or table names. For example, if a managed Kudu table created from Impala is named impala::bar.foo, its database will be impala::bar.

Table: Is a single Kudu table.

Column: Is a column within a Kudu table.

If a user has the ALL privileges on a given table specifically, then that user has all of the above privileges on the table. METADATA privilege is modeled as any privilege. If a user has any privilege on a given table, that user has METADATA privileges on the table, i.e. a privilege granted on any action on a table implies that the user has the METADATA privilege on that table.

In term of privilege evaluation Ranger doesn't have the concept of hierarchical implication. To be more specific, if a user has SELECT privilege on a database, it does not imply that user has SELECT privileges on every table belonging to that database. On the other hand, Ranger supports privilege wildcard matching. For example, db=a->table=\* matches all the tables that belong to database a. Therefore, in Ranger users actually need the SELECT privilege on db=a->table=*->column=* to match the semantics of the SELECT privilege on db=a in Sentry.

Nevertheless, with Ranger integration, when a Kudu master receives a request, it consults Ranger to determine what privileges a user has. And the required policies documented in the <<security.adoc#policy-for-kudu-masters, policy section>> are enforced to determine whether the user is authorized to perform the requested action or not.