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
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
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
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.