Hive SQL Syntax for Use with Sentry
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.
GRANT SELECT(column_name) ON TABLE table_name TO ROLE role_name;The following command can be used to revoke the SELECT privilege on a column:
REVOKE SELECT(column_name) ON TABLE table_name FROM ROLE role_name;Any new columns added to a table will be inaccessible by default, until explicitly granted access.
SELECT column_name FROM TABLE table_name;In this case, Sentry will first check to see if the user has the required privileges to access the table. It will then further check to see whether the user has the SELECT privilege to access the column(s).
SELECT COUNT(column_name) FROM TABLE table_name;Users are also allowed to use the COUNT function to return the number of values in the column.
SELECT column_name FROM TABLE table_name WHERE column_name <operator> GROUP BY column_name;The above command will work as long as you refer only to columns to which you already have access.
To list the column(s) to which the current user has SELECT access:
- If a user has SELECT access to all columns in a table, the following command will work. Note that this is an exception, not the norm. In all other cases,
SELECT on all columns does not allow you to perform table-level operations.
SELECT * FROM TABLE table_name;
- The DESCRIBE table command differs from the others, in that it does not filter out columns for which the user does not have SELECT access.
- Column-level privileges can only be applied to tables and partitions, not 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.
CREATE ROLE StatementThe 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/drop roles. By default, the hive, impala and hue users have admin privileges in Sentry.
CREATE ROLE [role_name];
DROP ROLE StatementThe 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];
GRANT ROLE StatementThe 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 <groupName> [,GROUP <groupName>]
REVOKE ROLE StatementThe 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 <groupName> [,GROUP <groupName>]
GRANT <PRIVILEGE> StatementIn order to grant privileges on an object to a role, the user must be a Sentry admin user.
GRANT <PRIVILEGE> [, <PRIVILEGE> ] ON <OBJECT> <object_name> TO ROLE <roleName> [,ROLE <roleName>]
GRANT SELECT(column_name) ON TABLE table_name TO ROLE role_name;
REVOKE <PRIVILEGE> StatementSince only authorized admin users can create roles, consequently only Sentry admin users can revoke privileges from a group.
REVOKE <PRIVILEGE> [, <PRIVILEGE> ] ON <OBJECT> <object_name> FROM ROLE <roleName> [,ROLE <roleName>]You can also revoke any previously-granted SELECT privileges on specific columns of a table. For example:
REVOKE SELECT(column_name) ON TABLE table_name FROM ROLE role_name;
GRANT <PRIVILEGE> ... WITH GRANT OPTION
GRANT <PRIVILEGE> ON <OBJECT> <object_name> TO ROLE <roleName> WITH GRANT OPTIONOnly a role with GRANT option on a specific privilege or its parent privilege can revoke that privilege from other roles. Once the following statement is executed, all privileges with and without grant option are revoked.
REVOKE <PRIVILEGE> ON <OBJECT> <object_name> FROM ROLE <roleName>Hive does not currently support revoking only the WITH GRANT OPTION from a privilege previously granted to a role. To remove the WITH GRANT OPTION, revoke the privilege and grant it again without the WITH GRANT OPTION flag.
SET ROLE Statement
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.
- To list the database(s) for which the current user has database, table, or column-level access:
- To list the table(s) for which the current user has table or column-level access:
To list the column(s) to which the current user has SELECT access:
- To list all the roles in the system (only for sentry admin users):
To list all the roles in effect for the current user session:
SHOW CURRENT ROLES;
- To list all the roles assigned to the given <groupName> (only allowed for Sentry admin users and others users that are part of the group specified
SHOW ROLE GRANT GROUP <groupName>;
The SHOW statement can also be used to list the privileges that have been granted to a role or all the grants given to a role for a particular object.To list all the grants for the given <roleName> (only allowed for Sentry admin users and other users that have been granted the role specified by <roleName>). The following command will also list any column-level privileges:
SHOW GRANT ROLE <roleName>;
- To list all the grants for a role on the given <objectName> (only allowed for Sentry admin users and other users that have been granted the role
specified by <roleName>). The following command will also list any column-level privileges:
SHOW GRANT ROLE <roleName> on OBJECT <objectName>;
Example: Using Grant/Revoke Statements to Match an Existing Policy File
[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 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;