Cloudera Enterprise 5.15.x | Other versions

Managing the Sentry Service

This topic describes basic Sentry terminology and the Sentry privilege model:

Terminology

  • 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
    INSERT DB, TABLE
    SELECT SERVER, DB, TABLE, COLUMN
    UPDATE COLLECTION, CONFIG
    QUERY COLLECTION, CONFIG
    ALL SERVER, TABLE, DB, URI, COLLECTION, CONFIG
  • 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.

Privilege Model

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.
  • Privileges granted on URIs are recursively applied to all subdirectories. That is, privileges only need to be granted on the parent directory.
  • 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.
  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 and Authorization Privilege Model for Solr.

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

User to Group Mapping

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

You can configure Sentry to use Hadoop groups. By default, Sentry looks up groups locally, but it can be configured to look up Hadoop groups using LDAP (for Active Directory). User/group information for Sentry, Hive and Impala must be made available for lookup on the following hosts:
  • Sentry - Groups are looked up on the host the Sentry Server runs on.
  • Hive - Groups are looked up on the hosts running HiveServer2 and the Hive Metastore.
  • Impala - Groups are looked up on the Catalog Server and on all of the Impala daemon hosts.

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.

Authorization Privilege Model for Hive and Impala

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.

Object Hierarchy

Server
     URI
     Database
         Table
             Partition
             Columns
         View
Table 2. Valid privilege types and objects they apply to
Privilege Object
INSERT DB, TABLE
SELECT DB, TABLE, VIEW, COLUMN
ALL SERVER, TABLE, DB, URI
Table 3. Privilege hierarchy
Base Object Granular privileges on object Container object that contains the base object Privileges on container object that implies privileges on the base object
DATABASE ALL SERVER ALL
TABLE INSERT DATABASE ALL
TABLE SELECT DATABASE ALL
COLUMN SELECT DATABASE ALL
VIEW SELECT DATABASE ALL
Table 4. Privilege table for Hive & Impala operations
Operation Scope Privileges Required URI
CREATE DATABASE SERVER ALL  
DROP DATABASE DATABASE ALL  
CREATE TABLE DATABASE ALL  
DROP TABLE TABLE ALL  
CREATE VIEW

-This operation is allowed if you have column-level SELECT access to the columns being used.

 DATABASE; SELECT on TABLE; ALL  
ALTER VIEW

-This operation is allowed if you have column-level SELECT access to the columns being used.

 VIEW/TABLE ALL  
DROP VIEW VIEW/TABLE ALL  
ALTER TABLE .. ADD COLUMNS TABLE ALL  
ALTER TABLE .. REPLACE COLUMNS TABLE ALL  
ALTER TABLE .. CHANGE column TABLE ALL  
ALTER TABLE .. RENAME TABLE ALL  
ALTER TABLE .. SET TBLPROPERTIES TABLE ALL  
ALTER TABLE .. SET FILEFORMAT TABLE ALL  
ALTER TABLE .. SET LOCATION TABLE ALL URI
ALTER TABLE .. ADD PARTITION TABLE ALL  
ALTER TABLE .. ADD PARTITION location TABLE ALL URI
ALTER TABLE .. DROP PARTITION TABLE ALL  
ALTER TABLE .. PARTITION SET FILEFORMAT TABLE ALL  
SHOW CREATE TABLE TABLE SELECT/INSERT  
SHOW PARTITIONS TABLE SELECT/INSERT  
SHOW TABLES

-Output includes all the tables for which the user has table-level privileges and all the tables for which the user has some column-level privileges.

 TABLE SELECT/INSERT  
SHOW GRANT ROLE

-Output includes an additional field for any column-level privileges.

 TABLE SELECT/INSERT  
DESCRIBE TABLE

-Output shows all columns if the user has table level-privileges or SELECT privilege on at least one table column

 TABLE SELECT/INSERT  
LOAD DATA TABLE INSERT URI
SELECT

-You can grant the SELECT privilege on a view to give users access to specific columns of a table they do not otherwise have access to.

-See Column-level Authorization for details on allowed column-level operations.

 VIEW/TABLE; COLUMN SELECT  
INSERT OVERWRITE TABLE TABLE INSERT  
CREATE TABLE .. AS SELECT

-This operation is allowed if you have column-level SELECT access to the columns being used.

 DATABASE; SELECT on TABLE ALL  
USE <dbName> Any    
CREATE FUNCTION SERVER ALL  
ALTER TABLE .. SET SERDEPROPERTIES TABLE ALL  
ALTER TABLE .. PARTITION SET SERDEPROPERTIES TABLE ALL  
Table 5. Privilege table for Hive-only operations
Operation Scope Privileges Required URI
INSERT OVERWRITE DIRECTORY TABLE INSERT URI
Analyze TABLE TABLE SELECT + INSERT  
IMPORT TABLE DATABASE ALL URI
EXPORT TABLE TABLE SELECT URI
ALTER TABLE TOUCH TABLE ALL  
ALTER TABLE TOUCH PARTITION TABLE ALL  
ALTER TABLE .. CLUSTERED BY SORTED BY TABLE ALL  
ALTER TABLE .. ENABLE/DISABLE TABLE ALL  
ALTER TABLE .. PARTITION ENABLE/DISABLE TABLE ALL  
ALTER TABLE .. PARTITION.. RENAME TO PARTITION TABLE ALL  
MSCK REPAIR TABLE TABLE ALL  
ALTER DATABASE DATABASE ALL  
DESCRIBE DATABASE DATABASE SELECT/INSERT  
SHOW COLUMNS

-Output for this operation filters columns to which the user does not have explicit SELECT access

 TABLE SELECT/INSERT  
CREATE INDEX TABLE ALL  
DROP INDEX TABLE ALL  
SHOW INDEXES TABLE SELECT/INSERT  
GRANT PRIVILEGE Allowed only for Sentry admin users    
REVOKE PRIVILEGE Allowed only for Sentry admin users    
SHOW GRANT Allowed only for Sentry admin users    
SHOW TBLPROPERTIES TABLE SELECT/INSERT  
DESCRIBE TABLE .. PARTITION TABLE SELECT/INSERT  
ADD ARCHIVE[S] Not Allowed    
ADD FILE[S] Not Allowed    
ADD JAR[S] Not Allowed    
DELETE JAR[S] Not Allowed    
DFS Not Allowed    
LIST JAR[S] Not Allowed    
Table 6. Privilege table for Impala-only operations
Operation Scope Privileges Required URI
EXPLAIN INSERT TABLE; COLUMN INSERT  
EXPLAIN SELECT TABLE; COLUMN SELECT  
INVALIDATE METADATA SERVER ALL  
INVALIDATE METADATA <table name> TABLE SELECT/INSERT  
REFRESH <table name> or REFRESH <table name> PARTITION (<partition_spec>) TABLE SELECT/INSERT  
DROP FUNCTION SERVER ALL  
COMPUTE STATS TABLE ALL  

Authorization Privilege Model for Solr

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 7. Privilege table for non-administrative request handlers
Request Handler Required Collection Privilege Collections that Require Privilege
select QUERY collection1
query QUERY collection1
get QUERY collection1
browse QUERY collection1
tvrh QUERY collection1
clustering QUERY collection1
terms QUERY collection1
elevate QUERY collection1
analysis/field QUERY collection1
analysis/document QUERY collection1
update UPDATE collection1
update/json UPDATE collection1
update/csv UPDATE collection1
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
Table 9. Privilege table for core admin actions
Collection Action Required Collection Privilege Collections that Require Privilege
create UPDATE admin, collection1
rename UPDATE admin, collection1
load UPDATE admin, collection1
unload UPDATE admin, collection1
status UPDATE admin, collection1
persist UPDATE admin
reload UPDATE admin, collection1
swap UPDATE admin, collection1
mergeIndexes UPDATE admin, collection1
split UPDATE admin, collection1
prepRecover UPDATE admin, collection1
requestRecover UPDATE admin, collection1
requestSyncShard UPDATE admin, collection1
requestApplyUpdates UPDATE admin, collection1
Table 10. Privilege table for Info and AdminHandlers
Request Handler Required Collection Privilege Collections that Require Privilege
LukeRequestHandler QUERY admin
SystemInfoHandler QUERY admin
SolrInfoMBeanHandler QUERY admin
PluginInfoHandler QUERY admin
ThreadDumpHandler QUERY admin
PropertiesRequestHandler QUERY admin
LoginHandler QUERY, UPDATE (or *) admin
ShowFileRequestHandler QUERY admin
Table 11. Privilege table for Config Admin actions
Config Action Required Collection Privilege Collections that Require Privilege Required Config Privilege Configs that Require Privilege
CREATE UPDATE admin * config1
DELETE UPDATE admin * config1
Page generated May 18, 2018.