Hadoop Groups

Locate the Sentry User to Group Mapping Class property or search for it by typing its name in the Search box.

Set the Sentry User to Group Mapping Class property to org.apache.sentry.provider.file.HadoopGroupResourceAuthorizationProvider.

Click Save Changes.

Restart the Hive service.

Local Groups

Note: You can use either Hadoop groups or local groups, but not both at the same time. Use local groups if you want to do a quick proof-of-concept.
For production, use Hadoop groups.

Define local groups in the [users] section of the Policy File. For example:

[users]
user1 = group1, group2, group3
user2 = group2, group3

Modify Sentry configuration as follows:

Go to the Hive service.

Click the Configuration tab.

Select Scope > Hive (Service-Wide).

Select Category > Policy File Based Sentry.

Locate the Sentry User to Group Mapping Class property or search for it by typing its name in the Search box.

Set the Sentry User to Group Mapping Class property to org.apache.sentry.provider.file.LocalGroupResourceAuthorizationProvider.

Click Save Changes.

Restart the Hive service.

Enabling URIs for Per-DB Policy Files

The ADD JAR command does not work with HiveServer2 and the Beeline client when Beeline runs on a different host. As an alternative
to ADD JAR, Hive's auxiliary paths functionality should be used as described in the following steps.
Important: Enabling URIs in per-DB policy files introduces a security risk by allowing the owner of the db-level policy file to grant
himself/herself load privileges to anything the hive user has read permissions for in HDFS (including data in other databases controlled by different db-level policy
files).
Add the following string to the Java configuration options for HiveServer2 during startup.

-Dsentry.allow.uri.db.policyfile=true

Using User-Defined Functions with HiveServer2

The ADD JAR command does not work with HiveServer2 and the Beeline client when Beeline runs on a different host. As an alternative to
ADD JAR, Hive's auxiliary paths functionality should be used. There are some differences in the procedures for creating permanent functions and
temporary functions. For detailed instructions, see User-Defined Functions (UDFs) with HiveServer2 Using Cloudera Manager.

If you set hive.warehouse.subdir.inherit.perms to true in hive-site.xml, the permissions
on the subdirectories will be set when you set permissions on the warehouse directory itself.

If a user has access to any object in the warehouse, that user will be able to execute use default. This ensures that use default commands issued by legacy applications work when Sentry is enabled. Note that you can protect objects in the default database (or any other database) by means of
a policy file.

Important: These instructions override the recommendations in the Hive section of the CDH 5 Installation Guide.

Disable impersonation for HiveServer2:

Go to the Hive service.

Click the Configuration tab.

Select Scope > HiveServer2.

Select Category > All.

Locate the HiveServer2 Enable Impersonation property or search for it by typing its name in the Search box.

Under the HiveServer2 role group, deselect the HiveServer2 Enable Impersonation property.

Click Save Changes to commit the changes.

Create the Sentry policy file, sentry-provider.ini, as an HDFS file.

Enable the Hive user to submit MapReduce jobs.

Go to the MapReduce service.

Click the Configuration tab.

Select Scope > TaskTracker.

Select Category > Security.

Locate the Minimum User ID for Job Submission property or search for it by typing its name in the Search box.

Set the Minimum User ID for Job Submission property to 0 (the default is 1000).

Click Save Changes to commit the changes.

Repeat steps 5.a-5.d for every TaskTracker role group for the MapReduce service that is associated with Hive, if more than one exists.

Restart the MapReduce service.

Enable the Hive user to submit YARN jobs.

Go to the YARN service.

Click the Configuration tab.

Select Scope > NodeManager.

Select Category > Security.

Ensure the Allowed System Users property includes the hive user. If not, add hive.

Click Save Changes to commit the changes.

Repeat steps 6.a-6.d for every NodeManager role group for the YARN service that is associated with Hive, if more than one exists.

Restart the YARN service.

Go to the Hive service.

Click the Configuration tab.

Select Scope > Hive (Service-Wide).

Select Category > Policy File Based Sentry.

Select Enable Sentry Authorization Using Policy Files.

Click Save Changes to commit the changes.

Add the Hive user group to Sentry's admin groups.

Go to the Sentry service.

Click the Configuration tab.

Select Scope > Sentry (Service-Wide).

Select Category > Main.

Locate the Admin Groups property and add the hive group to the list. If an end user is in one of these admin groups, that
user has administrative privileges on the Sentry Server.

Click Save Changes to commit the changes.

Restart the cluster and HiveServer2 after changing these values, whether you use Cloudera Manager or not.

Configuring Group Access to the Hive Metastore

You can configure the Hive Metastore to reject connections from users not listed in the Hive group proxy list (in HDFS). If you do not configure this override, the Hive Metastore will
use the value in the core-site HDFS configuration. To configure the Hive group proxy list:

Go to the Hive service.

Click the Configuration tab.

Select Scope > Hive (Service-Wide).

Select Category > Proxy.

In the Hive Metastore Access Control and Proxy User Groups Override property, specify a list of groups whose users are allowed to access the Hive
Metastore. If you do not specify "*" (wildcard), you will be warned if the groups do not include hive and impala (if the Impala service is configured) in the list of groups.

Click Save Changes.

Restart the Hive service.

Enabling Policy File Authorization for Impala

For a cluster managed by Cloudera Manager, perform the following steps to enable policy file authorization for Impala.

Enabling Sentry Authorization for Solr

Create the policy file sentry-provider.ini as an HDFS file. When you create the policy file sentry-provider.ini follow
the instructions in the Policy File section in Configuring Sentry for Search (CDH 4) orSearch Authentication. The file must be owned by owned by the solr user in the solr group, with perms=600. By default Cloudera Manager assumes the policy file is in the HDFS location /user/solr/sentry. To configure the location:

Configuring Sentry to Enable BDR Replication

Cloudera recommends the following steps when configuring Sentry and data
replication is enabled.

Group membership should be managed outside of Sentry (as typically OS groups, LDAP groups, and so on are managed) and replication for them also should be handled outside of Cloudera
Manager.

In Cloudera Manager, set up HDFS replication for the Sentry files of the databases that are being replicated
(separately using Hive replication).

On the source cluster:

Use a separate Sentry policy file for every database

Avoid placing any group or role info (except for server admin info) in the global Sentry policy file (to avoid manual replication/merging with the global file on the target
cluster)

To avoid manual fix up of URI privileges, ensure that the URIs for the data are the same on both the source and target cluster

On the target cluster:

In the global Sentry policy file, manually add the DB name - DB file mapping entries for the databases being
replicated

Manually copy the server admin info from the global Sentry policy file on the source to the policy on the target cluster

For the databases being replicated, avoid adding more privileges (adding tables specific to target cluster may sometimes require adding extra privileges to allow access to those
tables). If any target cluster specific privileges absolutely need to be added for a database, add them to the global Sentry policy file on the target cluster since the per database files would be
overwritten periodically with source versions during scheduled replication.

If this documentation includes code, including but not limited to, code examples, Cloudera makes this available to you under the terms of the Apache License, Version 2.0, including any required
notices. A copy of the Apache License Version 2.0 can be found here.