Privileges can be granted on different objects in the schema. 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 child object automatically inherits it. This is the same privilege model as Hive and other database systems.

The objects in the Impala schema hierarchy are:

Server
    URI
    Database
        Table
            Column

The server name is specified by the -server_name option when impalad starts. Specify the same name for all impalad nodes in the cluster.

URIs represent the file paths you specify as part of statements such as CREATE EXTERNAL TABLE and LOAD DATA. Typically, you specify what look like UNIX paths, but these locations can also be prefixed with hdfs:// to make clear that they are really URIs. To set privileges for a URI, specify the name of a directory, and the privilege applies to all the files in that directory and any directories underneath it.

GRANT ALL ON URI '/tmp';

GRANT ALL ON URI 'hdfs://localhost:20500/tmp';

When defining URIs for HDFS, you must also specify the NameNode. For example:

GRANT ALL ON URI file:///path/to/dir TO <role>
GRANT ALL ON URI hdfs://namenode:port/path/to/dir TO <role>

  Warning:

Because the NameNode host and port must be specified, Cloudera strongly recommends you use High Availability (HA). This ensures that the URI will remain constant even if the NameNode changes. For example:

GRANT ALL ON URI hdfs://ha-nn-uri/path/to/dir TO <role>

The table-level privileges apply to views as well. Anywhere you specify a table name, you can specify a view name instead.

In CDH 5.5 / Impala 2.3 and higher, you can specify privileges for individual columns, as described in Column-level Authorization.

The following privileges determines what you can do with each object:

ALL privilege

Lets you create or modify the object. Required to run DDL statements such as CREATE TABLE, ALTER TABLE, or DROP TABLE for a table, CREATE DATABASE or DROP DATABASE for a database, or CREATE VIEW, ALTER VIEW, or DROP VIEW for a view. Also required for the URI of the "location" parameter for the CREATE EXTERNAL TABLE and LOAD DATA statements.

SELECT privilege

Lets you read data from a table or view, for example with the SELECT statement, the INSERT...SELECT syntax, or CREATE TABLE...LIKE. Also required to issue the DESCRIBE statement or the EXPLAIN SELECT statement for a query against a particular table. Only objects for which a user has this privilege are shown in the output for SHOW DATABASES and SHOW TABLES statements. The REFRESH statement and INVALIDATE METADATA statements only access metadata for tables for which the user has this privilege.

INSERT privilege

Lets you write data to a table. Applies to the INSERT, TRUNCATE and LOAD DATA statements.

Originally, privileges were encoded in a policy file, stored in HDFS. This mode of operation is still an option, but the emphasis of privilege management is moving towards being SQL-based. The mode of operation with GRANT and REVOKE statements instead of the policy file requires that a special Sentry service be enabled; this service stores, retrieves, and manipulates privilege information stored inside the metastore database.

  Note:

Although this document refers to the ALL privilege, currently if you use the policy file mode, you do not use the actual keyword ALL in the policy file. When you code role entries in the policy file:

• To specify the ALL privilege for a server, use a role like server=server_name.
• To specify the ALL privilege for a database, use a role like server=server_name->db=database_name.
• To specify the ALL privilege for a table, use a role like server=server_name->db=database_name->table=table_name->action=*.

If you change privileges in Sentry, e.g. adding a user, removing a user, modifying privileges, you must clear the Impala Catalog server cache by running the INVALIDATE METADATA statement. INVALIDATE METADATA is not required if you make the changes to privileges within Impala.

When you use the Sentry service, you set up privileges through the GRANT and REVOKE statements in either Impala or Hive. Then both components use those same privileges automatically. (Impala added the GRANT and REVOKE statements in CDH 5.2 / Impala 2.0.)

For information about using the Impala GRANT and REVOKE statements, see GRANT Statement (CDH 5.2 or higher only) and REVOKE Statement (CDH 5.2 or higher only).

The policy file is a file that you put in a designated location in HDFS, and is read during the startup of the impalad daemon when you specify both the -server_name and -authorization_policy_file startup options. It controls which objects (databases, tables, and HDFS directory paths) can be accessed by the user who connects to impalad, and what operations that user can perform on the objects.

  Note:

In CDH 5 and higher, Cloudera recommends managing privileges through SQL statements, as described in Using Impala with the Sentry Service (CDH 5.1 or higher only). If you are still using policy files, plan to migrate to the new approach some time in the future.

The location of the policy file is listed in the auth-site.xml configuration file.

When authorization is enabled, Impala uses the policy file as a whitelist, representing every privilege available to any user on any object. That is, only operations specified for the appropriate combination of object, role, group, and user are allowed. All other operations are not allowed. If a group or role is defined multiple times in the policy file, the last definition takes precedence.

To understand the notion of whitelisting, set up a minimal policy file that does not provide any privileges for any object. When you connect to an Impala node where this policy file is in effect, you get no results for SHOW DATABASES, and an error when you issue any SHOW TABLES, USE database_name, DESCRIBE table_name, SELECT, and or other statements that expect to access databases or tables, even if the corresponding databases and tables exist.

The contents of the policy file are cached, to avoid a performance penalty for each query. The policy file is re-checked by each impalad node every 5 minutes. When you make a non-time-sensitive change such as adding new privileges or new users, you can let the change take effect automatically a few minutes later. If you remove or reduce privileges, and want the change to take effect immediately, restart the impalad daemon on all nodes, again specifying the -server_name and -authorization_policy_file options so that the rules from the updated policy file are applied.

In your role definitions, you must specify privileges at the level of individual databases and tables, or all databases or all tables within a database. To simplify the structure of these rules, plan ahead of time how to name your schema objects so that data with different authorization requirements is divided into separate databases.

If you are adding security on top of an existing Impala deployment, you can rename tables or even move them between databases using the ALTER TABLE statement.

Because of the extra emphasis on granular access controls in a secure deployment, you should move any important or sensitive information out of the DEFAULT database into a named database whose privileges are specified in the policy file. Sometimes you might need to give privileges on the DEFAULT database for administrative reasons; for example, as a place you can reliably specify with a USE statement when preparing to drop a database.