• An object is an entity protected by Sentry's authorization rules. The objects supported in the current release are server, database, table, URI, collection, and config.
• A role is a collection of rules for accessing a given object.
• A privilege is granted to a role to govern access to an object. Sentry allows you to assign the SELECT privilege to columns (only for Hive and Impala). Supported privileges are:

  Table 1. Valid privilege types and the objects they apply to

  Privilege	Object
  ALL	SERVER, TABLE, DB, URI
  CREATE	SERVER, DATABASE
  INSERT	SERVER, DB, TABLE
  REFRESH (Impala only)	SERVER, DATABASE, TABLE
  SELECT	SERVER, DB, TABLE, COLUMN

• A user is an entity that is permitted by the authentication subsystem to access the service. This entity can be a Kerberos principal, an LDAP userid, or an artifact of some other supported pluggable authentication system.
• A group connects the authentication system with the authorization system. It is a collection of one or more users who have been granted one or more authorization roles. Sentry allows a set of roles to be configured for a group.
• A configured group provider determines a user’s affiliation with a group. The current release supports HDFS-backed groups and locally configured groups.

Sentry uses a role-based privilege model with the following characteristics.

• Allows any user to execute show function, desc function, and show locks.
• Allows the user to see only those tables, databases, collections, and configurations for which the user has privileges.
• Requires a user to have the necessary privileges on the URI to execute HiveQL operations that specify a location. Examples of such operations include LOAD, IMPORT, and EXPORT.
• Sentry provides column-level access control for tables in Hive and Impala. You can assign the SELECT privilege on a subset of columns in a table.
• In Beeline, you can grant privileges on an object that doesn't exist. For example, you can grant role1 on table1 and then create table1.

  Important:

• When Sentry is enabled, you must use Beeline to execute Hive queries. Hive CLI is not supported with Sentry and must be disabled.
• When Sentry is enabled, a user with no privileges on a database will not be allowed to connect to HiveServer2. This is because the use <database> command is executed as part of the connection to HiveServer2, which is why the connection fails. See HIVE-4256.

For more information, see Authorization Privilege Model for Hive and Impala, Authorization Privilege Model for Solr, and Using Kafka with Sentry Authorization.

Granting Privileges

  Note: In the following example(s), server1 refers to an alias Sentry uses for the associated Hive service. It does not refer to any physical server. This alias can be modified using the hive.sentry.server property in hive-site.xml. If you are using Cloudera Manager, modify the Hive property, Server Name for Sentry Authorization, in the Service-Wide > Advanced category.

For example, a rule for the Select privilege on table customers from database sales is formulated as follows:

server=server1->db=sales->table=customer->action=Select

To assign the Select privilege to the sales_read role on the Id column from the customers table, the rule would be as follows:

sales_read = server=server1->db=sales->table=customers->column=Id->action=select

Each object must be specified as a hierarchy of the containing objects, from server to table, followed by the privilege granted for that object. A role can contain multiple such rules, separated by commas. For example, a role might contain the Select privilege for the customer and items tables in the sales database, and the Insert privilege for the sales_insights table in the reports database. You would specify this as follows:

sales_reporting =                                            \
server=server1->db=sales->table=customer->action=Select,     \
server=server1->db=sales->table=items->action=Select,         \
server=server1->db=reports->table=sales_insights->action=Insert

Grant permissions on URIs to create functions, alter the location of a table, explicitly set the location of a table, and to import and export from a table with that location. A user must have ALL permissions on the URI to perform the following actions:

For example, if you create the following table with an S3 location:

CREATE EXTERNAL TABLE mytesttable (firstname STRING, lastname STRING, address STRING, city STRING, state STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LOCATION 's3a://mybucket/';

To insert data into the table, you must have ALL on the URI 's3a://mybucket' to execute the following command:

INSERT INTO TABLE mytesttable VALUES ('bilbo', 'baggends', 'bagend', 'hobbiton', 'shire');

The URI represents the HDFS path you specify as part of a GRANT statement. The URI in the statement can look like a UNIX path, but can also be prefixed with hdfs:// to clarify that it is a URI.

The following command is an example of a GRANT privilege on a URI:

GRANT ALL ON URI '/user/hive/warehouse/customers' TO ROLE t_rex

The only privilege you can grant on a URI is ALL. For details about the GRANT ALL ON URI statement, see GRANT <Privilege> ON URIs (HDFS and S3A).

URIs are not applied as HDFS ACLs. The How-To article and video, How to Verify that HDFS ACLs are Synching with Sentry , gives an example of a GRANT statement on a URI that does not affect an HDFS ACL change. For information on what does trigger an HDFS ACL change, see Prompting HDFS ACL Changes.

  Warning: Because the NameNode host and port are used when you grant privileges on a URI, it is strongly recommended that you use HDFS High Availability (HA). This ensures that the URI will remain constant even if the NameNode changes.

Minimum Required Role: Configurator (also provided by Cluster Administrator, Full Administrator)

Group mappings in Sentry can be summarized as in the figure below.

The Sentry service only uses HadoopUserGroup mappings. See Configuring LDAP Group Mappings for details on configuring LDAP group mappings in Hadoop.

Privileges can be granted on different objects in the Hive warehouse. Any privilege that can be granted is associated with a level in the object hierarchy. If a privilege is granted on a container object in the hierarchy, the base object automatically inherits it. For instance, if a user has ALL privileges on the database scope, then (s)he has ALL privileges on all of the base objects contained within that scope.

  Important:

Note that because of this object hierarchy, it is possible for a user to read data from a database that the user does not have access to. For example, you have two roles:

• role1 - full access to database1 and database2
• role2 - full access to database1, no access to database2

A user with role1 can create a view in database1 based on a table in database2. Because role2 has access to database1, a user with role2 can read the data in that view from database2.

The tables below refer to the request handlers defined in the generated solrconfig.xml.secure. If you are not using this configuration file, the below may not apply.

admin is a special collection in Sentry used to represent administrative actions. A non-administrative request may only require privileges on the collection or config on which the request is being performed. This is called either collection1 or config1 in these tables. An administrative request may require privileges on both the admin collection and collection1. This is denoted as admin, collection1 in the tables below.

  Note: If no privileges are granted, no access is possible. For example, accessing the Solr Admin UI requires the QUERY privilege. If no users are granted the QUERY privilege, no access to the Solr Admin UI is possible.

Table 8. Privilege table for collections admin actions

Collection Action	Required Collection Privilege	Collections that Require Privilege
create	UPDATE	admin, collection1
delete	UPDATE	admin, collection1
reload	UPDATE	admin, collection1
createAlias	UPDATE	admin, collection1   Note: collection1 here refers to the name of the alias, not the underlying collection(s). For example, http://YOUR-HOST:8983/ solr/admin/collections?action= CREATEALIAS&name=collection1 &collections=underlyingCollection
deleteAlias	UPDATE	admin, collection1   Note: collection1 here refers to the name of the alias, not the underlying collection(s). For example, http://YOUR-HOST:8983/ solr/admin/collections?action= DELETEALIAS&name=collection1
syncShard	UPDATE	admin, collection1
splitShard	UPDATE	admin, collection1
deleteShard	UPDATE	admin, collection1