Sentry allows you to assign the SELECT privilege on a subset of columns in a table.

GRANT SELECT <column name> ON TABLE <table name> TO ROLE <role name>;

REVOKE SELECT <column name> ON TABLE <table name> FROM ROLE <role name>;

Actions allowed for users with SELECT privilege on a column:

Limitations:

• Column-level privileges can only be applied to tables, not partitions or views.
• HDFS-Sentry Sync: With HDFS-Sentry sync enabled, even if a user has been granted access to all columns of a table, they will not have access to the corresponding HDFS data files. This is because Sentry does not consider SELECT on all columns equivalent to explicitly being granted SELECT on the table.
• Column-level access control for access from Spark SQL is not supported by the HDFS-Sentry plug-in.

The CREATE ROLE statement creates a role to which privileges can be granted. Privileges can be granted to roles, which can then be assigned to users. A user that has been assigned a role will only be able to exercise the privileges of that role.

Only users that have administrative privileges can create or drop roles. By default, the hive, impala and hue users have admin privileges in Sentry.

CREATE ROLE <role name>;

Note that role names are case-insensitive.

The DROP ROLE statement can be used to remove a role from the database. Once dropped, the role will be revoked for all users to whom it was previously assigned. Queries that are already executing will not be affected. However, since Hive checks user privileges before executing each query, active user sessions in which the role has already been enabled will be affected.

DROP ROLE <role name>;

The GRANT ROLE statement can be used to grant roles to groups. Only Sentry admin users can grant roles to a group.

GRANT ROLE <role name> [, <role name>]
    TO GROUP <group name> [,GROUP <group name>]

GRANT ROLE test TO GROUP test-group;

GRANT ROLE test TO GROUP `test-group`;

GRANT ROLE test TO GROUP test_group;

Operating system group names must be in lowercase letters. Although group names are case-insensitive to Sentry, Sentry modifies capital letters within group names to be lowercase. For example, Sentry will change TestGroup to testgroup. It is not possible to disable this normalization. Therefore, group information within the environment must be in lowercase letters.

The REVOKE ROLE statement can be used to revoke roles from groups. Only Sentry admin users can revoke the role from a group.

REVOKE ROLE <role name> [, <role name>]
    FROM GROUP <group name> [,GROUP <group name>]

Use the GRANT <Privilege> statement to grant privileges on an object to a role. The statement uses the following syntax:

GRANT
    <privilege> [, <privilege> ]
    ON <object type> <object name>
    TO ROLE <role name> [,ROLE <role name>]

For example, you might enter the following statement:

GRANT SELECT ON TABLE feathered_dinosaurs TO ROLE archaeopteryx

The following table describes the privileges you can grant and the objects that they apply to:

GRANT SELECT <column name> ON TABLE <table name> TO ROLE <role name>;

If the GRANT for Sentry URI does not specify the complete scheme, or the URI mentioned in Hive DDL statements does not have a scheme, Sentry automatically completes the URI by applying the default scheme based on the HDFS configuration provided in the fs.defaultFS property. Using the same HDFS configuration, Sentry can also auto-complete URIs in case the URI is missing a scheme and an authority component.

When a user attempts to access a URI, Sentry will check to see if the user has the required privileges. During the authorization check, if the URI is incomplete, Sentry will complete the URI using the default HDFS scheme. Note that Sentry does not check URI schemes for completion when they are being used to grant privileges. This is because users can GRANT privileges on URIs that do not have a complete scheme or do not already exist on the filesystem.

For example, in CDH 5.8 and later, the following CREATE EXTERNAL TABLE statement works even though the statement does not include the URI scheme.

GRANT ALL ON URI 'hdfs://namenode:XXX/path/to/table' TO ROLE <role name>;
CREATE EXTERNAL TABLE foo LOCATION 'namenode:XXX/path/to/table' TO ROLE <role name>;

Similarly, the following CREATE EXTERNAL TABLE statement works even though it is missing scheme and authority components.

GRANT ALL ON URI 'hdfs://namenode:XXX/path/to/table' TO ROLE <role name>;
CREATE EXTERNAL TABLE foo LOCATION '/path/to/table'

You can use the REVOKE <Privilege> statement to revoke previously-granted privileges that a role has on an object.

REVOKE
    <privilege> [, <privilege> ]
    ON <object type> <object name>
    FROM ROLE <role name> [,ROLE <role name>]

REVOKE SELECT <column name> ON TABLE <table name> FROM ROLE <role name>;

You can add the WITH GRANT OPTION clause to a GRANT <PRIVILEGE> statement to allow the role to grant and revoke the privilege to and from other roles.

The WITH GRANT OPTION clause uses the following syntax:

GRANT
    <privilege>
    ON <object type> <object name>
    TO ROLE <role name>
    WITH GRANT OPTION

When you use the WITH GRANT OPTION clause, the ability to grant and revoke privileges applies to the object container and all its children. For example, if you give GRANT privileges to a role at the database level, that role can grant and revoke privileges to and from the database and all the tables in the database.

Only a role with the GRANT option on a privilege can revoke that privilege from other roles. And you cannot revoke the GRANT privilege from a role without also revoking the privilege. To revoke the GRANT privilege, revoke the privilege that it applies to and then grant that privilege again without the WITH GRANT OPTION clause.

You can use the WITH GRANT OPTION clause with the following privileges:

Sentry enforces restrictions on queries based on the roles and privileges that the user has. A user can have multiple roles and a role can have multiple privileges.

The SET ROLE command enforces restrictions at the role level, not at the user level. When you use the SET ROLE command to make a role active, the role becomes current for the session. If a role is not current for the session, it is inactive and the user does not have the privileges assigned to that role. A user can only use the SET ROLE command for roles that have been granted to the user.

To list the roles that are current for the user, use the SHOW CURRENT ROLES command. By default, all roles that are assigned to the user are current.

You can use the following SET ROLE commands:

SET ROLE NONE

Makes all roles for the user inactive. When no role is current, the user does not have any privileges and cannot execute a query.

SET ROLE ALL

Makes all roles that have been granted to the user active. All privileges assigned to those roles are applied. When the user executes a query, the query is filtered based on those privileges.

SET ROLE role name

Makes a single role active. The privileges assigned to that role are applied. When the user executes a query, the query is filtered based on the privileges assigned to that role.

Sentry supports the following privilege types:

  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.

[groups]
# Assigns each Hadoop group to its set of roles  
manager = analyst_role, junior_analyst_role 
analyst = analyst_role 
jranalyst = junior_analyst_role 
customers_admin = customers_admin_role 
admin = admin_role  

[roles] # The URIs below define a landing skid which
# the user can use to import or export data from the system. 
# Since the server runs as the user "hive" files in that directory 
# must either have the group hive and read/write set or 
# be world read/write. 
analyst_role = server=server1->db=analyst1, \     
    server=server1->db=jranalyst1->table=*->action=select         
    server=server1->uri=hdfs://ha-nn-uri/landing/analyst1 
junior_analyst_role = server=server1->db=jranalyst1, \     
    server=server1->uri=hdfs://ha-nn-uri/landing/jranalyst1  

# Implies everything on server1. 
admin_role = server=server1

The following sections show how you can use the new GRANT statements to assign privileges to roles (and assign roles to groups) to match the sample policy file above.

CREATE ROLE analyst_role;
GRANT ALL ON DATABASE analyst1 TO ROLE analyst_role;
GRANT SELECT ON DATABASE jranalyst1 TO ROLE analyst_role;
GRANT ALL ON URI 'hdfs://ha-nn-uri/landing/analyst1' \
TO ROLE analyst_role;

CREATE ROLE junior_analyst_role;
GRANT ALL ON DATABASE jranalyst1 TO ROLE junior_analyst_role;
GRANT ALL ON URI 'hdfs://ha-nn-uri/landing/jranalyst1' \
TO ROLE junior_analyst_role;

CREATE ROLE admin_role;
GRANT ALL ON SERVER server1 TO ROLE admin_role;

GRANT ROLE admin_role TO GROUP admin;
GRANT ROLE analyst_role TO GROUP analyst;
GRANT ROLE jranalyst_role TO GROUP jranalyst;