The Sentry Service

Important: This is the documentation for the Sentry service introduced in CDH 5.1. If you want to use Sentry's previous policy file approach
to secure your data, see Sentry Policy File Authorization.

The Sentry service is a RPC server that stores the authorization metadata in an underlying relational
database and provides RPC interfaces to retrieve and manipulate privileges. It supports secure access to services using Kerberos. The service serves authorization metadata from the database
backed storage; it does not handle actual privilege validation. The Hive, Impala, and Solr services are clients of this service and will enforce Sentry privileges when configured to use Sentry.

The motivation behind introducing a new Sentry service is to make it easier to handle user privileges than the existing policy file approach. Providing a service instead of a file allows
you to use the more traditional GRANT/REVOKE statements to modify privileges.

The rest of this topic will walk you through the prerequisites for Sentry, basic terminology, and the Sentry privilege model.

Prerequisites

HiveServer2 and the Hive Metastore running with strong authentication. For HiveServer2, strong authentication is either Kerberos or LDAP. For the
Hive Metastore, only Kerberos is considered strong authentication (to override, see Securing the Hive Metastore).

Impala 1.4.0 (or higher) running with strong authentication. With Impala, either Kerberos or LDAP can be configured to achieve strong authentication.

Cloudera Search for CDH 5.1.0 or higher. Solr supports using Sentry beginning with CDH 5.1.0. Different functionality is added at different releases:

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. With CDH 5.5, Sentry allows you to assign the SELECT privilege to
columns (only for Hive and Impala). Supported privileges are:

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, configs for which this user has privileges.

Requires a user to have the necessary privileges on the URI to execute HiveQL operations that take in 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.

CDH 5.5 introduces column-level access control for tables in Hive and Impala. Previously, Sentry supported privilege granularity only down to a table. Hence, if you wanted to restrict
access to a column of sensitive data, the workaround would be to first create view for a subset of columns, and then grant privileges on that view. To reduce the administrative overhead associated
with such an approach, Sentry now allows you to 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 now executed as part of the connection to HiveServer2, which is why the connection fails. See HIVE-4256.

User to Group Mapping

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.

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.

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.

Object Hierarchy

Server
URI
Database
Table
Partition
Columns
View

Valid privilege types and objects they apply to

Privilege

Object

INSERT

DB, TABLE

SELECT

DB, TABLE, VIEW, COLUMN

ALL

SERVER, TABLE, DB, URI

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

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

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.

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.

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

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, collection1Note: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, collection1Note: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

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.