jprdonnelly/impala
1
0
Fork 0
mirror of https://github.com/apache/impala.git synced 2025-12-25 02:03:09 -05:00
Code Issues Projects Releases Wiki Activity

IMPALA-9770: [DOCS] Remove Sentry references in documentation

Browse Source 
Updated all the associated topics.

Change-Id: Id4c5e9aa4d060ceaa426908a444d280a5564749d
Reviewed-on: http://gerrit.cloudera.org:8080/17469
Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>
Reviewed-by: Joe McDonnell <joemcdonnell@cloudera.com>
This commit is contained in:
Shajini Thayasingh
2021-05-14 15:49:54 -07:00
committed by Joe McDonnell
parent 20bdf9c96e
commit 1a84a1420c
25 changed files with 156 additions and 354 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
docs/shared/impala_common.xml
View File

@@ -4564,38 +4564,19 @@ CREATE EXTERNAL TABLE impala_name STORED AS KUDU
in the underlying Kudu table, in contrast to an HDFS-backed external
table where existing data files are left untouched.</p>
<p id="kudu_sentry_limitations" rev="IMPALA-4000">
Access to Kudu tables must be granted to and revoked from roles with the following
considerations:
<ul>
<li>
Only users with the <codeph>ALL</codeph> privilege on <codeph>SERVER</codeph> can
create external Kudu tables.
</li>
<li>
The <codeph>ALL</codeph> privileges on <codeph>SERVER</codeph> is required to
specify the <codeph>kudu.master_addresses</codeph> property in the <codeph>CREATE
TABLE</codeph> statements for managed tables as well as external tables.
</li>
<li>
Access to Kudu tables is enforced at the table level and at the column level.
</li>
<li>
The <codeph>SELECT</codeph>- and <codeph>INSERT</codeph>-specific permissions are
supported.
</li>
<li>
The <codeph>DELETE</codeph>, <codeph>UPDATE</codeph>, and <codeph>UPSERT</codeph>
operations require the <codeph>ALL</codeph> privilege.
</li>
</ul>
Because non-SQL APIs can access Kudu data without going through Sentry authorization,
currently the Sentry support is considered preliminary and subject to change.
</p>
<p id="kudu_sentry_limitations" rev="IMPALA-4000"> Access to Kudu tables must be granted to
and revoked from principal with the following considerations: <ul>
<li> Only users with the <codeph>ALL</codeph> privilege on <codeph>SERVER</codeph> can
create external Kudu tables. </li>
<li> The <codeph>ALL</codeph> privileges on <codeph>SERVER</codeph> is required to specify
the <codeph>kudu.master_addresses</codeph> property in the <codeph>CREATE TABLE</codeph>
statements for managed tables as well as external tables. </li>
<li> Access to Kudu tables is enforced at the table level and at the column level. </li>
<li> The <codeph>SELECT</codeph>- and <codeph>INSERT</codeph>-specific permissions are
supported. </li>
<li> The <codeph>DELETE</codeph>, <codeph>UPDATE</codeph>, and <codeph>UPSERT</codeph>
operations require the <codeph>ALL</codeph> privilege. </li>
</ul></p>
<p rev="2.9.0 IMPALA-5137" id="kudu_timestamp_nanoseconds_caveat">
The nanosecond portion of an Impala <codeph>TIMESTAMP</codeph> value is rounded to the

2
docs/topics/impala_adls.xml
View File

@@ -570,7 +570,7 @@ under the License.
</li>
<li>
Authorization using the Sentry framework to control access to databases, tables, or columns works the
Authorization using the Ranger framework to control access to databases, tables, or columns works the
same whether the data is in HDFS or in ADLS.
</li>

13
docs/topics/impala_alter_database.xml
View File

@@ -52,20 +52,17 @@ under the License.
</p>
<p>
The database owner is originally set to the user who creates the database. When object
ownership is enabled in Sentry, an owner of a database can have the <codeph>ALL</codeph>
with <codeph>GRANT</codeph> or <codeph>ALL</codeph> without <codeph>GRANT</codeph>
privilege. The term <codeph>OWNER</codeph> is used to differentiate between the
<codeph>ALL</codeph> privilege that is explicitly granted via the <codeph>GRANT</codeph>
statement and a privilege that is implicitly granted by the <codeph>CREATE
DATABASE</codeph> statement.
The database owner is originally set to the user who creates the database. The term
<codeph>OWNER</codeph> is used to differentiate between the <codeph>ALL</codeph>
privilege that is explicitly granted via the <codeph>GRANT</codeph> statement
and a privilege that is implicitly granted by the <codeph>CREATE DATABASE</codeph>
statement.
</p>
<p conref="../shared/impala_common.xml#common/syntax_blurb"/>
<codeblock>
ALTER DATABASE <varname>database_name</varname> SET OWNER USER user_name;
ALTER DATABASE <varname>database_name</varname> SET OWNER ROLE role_name;
</codeblock>
<p conref="../shared/impala_common.xml#common/ddl_blurb"/>

10
docs/topics/impala_alter_table.xml
View File

@@ -71,7 +71,6 @@ ALTER TABLE <varname>name</varname> DROP [COLUMN] <varname>column_name</varname>
ALTER TABLE <varname>name</varname> CHANGE <varname>column_name</varname> <varname>col_spec</varname>
<ph rev="3.1 IMPALA-6988">ALTER TABLE <varname>name</varname> SET OWNER USER <varname>user_name</varname>
ALTER TABLE <varname>name</varname> SET OWNER ROLE <varname>role_name</varname>
</ph>
<ph rev="2.10.0 IMPALA-4622">-- Kudu tables only.
ALTER TABLE <varname>name</varname> ALTER [COLUMN] <varname>column_name</varname>
@@ -319,21 +318,18 @@ alter table d2.mobile rename to d3.mobile;</codeblock>
</p>
<codeblock>ALTER TABLE <varname>name</varname> SET OWNER USER <varname>user_name;</varname>
ALTER TABLE <varname>name</varname> SET OWNER ROLE <varname>role_name;</varname>
</codeblock>
<p>
The table owner is originally set to the user who creates the table. When object ownership
is enabled in Sentry, an owner of a table can have the <codeph>ALL</codeph> with
<codeph>GRANT</codeph> or <codeph>ALL</codeph> without <codeph>GRANT</codeph> privilege.
The term <codeph>OWNER</codeph> is used to differentiate between the <codeph>ALL</codeph>
The table owner is originally set to the user who creates the table. The term
<codeph>OWNER</codeph> is used to differentiate between the <codeph>ALL</codeph>
privilege that is explicitly granted via the <codeph>GRANT</codeph> statement and a
privilege that is implicitly granted by the <codeph>CREATE TABLE</codeph> statement.
</p>
<p>
Use the <codeph>ALTER TABLE SET OWNER</codeph> to transfer the ownership from the current
owner to another user or a role.
owner to another user.
</p>
<p>

9
docs/topics/impala_alter_view.xml
View File

@@ -68,7 +68,6 @@ ALTER VIEW [<varname>database_name</varname>.]<varname>view_name</varname>
RENAME TO [<varname>database_name</varname>.]<varname>view_name</varname>;
ALTER VIEW [<varname>database_name</varname>.]<varname>view_name</varname> SET OWNER USER user_name;
ALTER VIEW [<varname>database_name</varname>.]<varname>view_name</varname> SET OWNER ROLE role_name;
</codeblock>
<ul>
@@ -102,12 +101,10 @@ ALTER VIEW db1.v1 RENAME TO db2.v1; -- Move the view to a difference database wi
<li rev="3.1 IMPALA-6988">
The <codeph>SET OWNER</codeph> clause transfers the ownership of the view from the
current owner to another user or a role.
current owner to another user.
<p>
The view owner is originally set to the user who creates the view. When object
ownership is enabled in Sentry, an owner of a view can have the <codeph>ALL</codeph>
with <codeph>GRANT</codeph> or <codeph>ALL</codeph> without <codeph>GRANT</codeph>
privilege. The term <codeph>OWNER</codeph> is used to differentiate between the
The view owner is originally set to the user who creates the view.
The term <codeph>OWNER</codeph> is used to differentiate between the
<codeph>ALL</codeph> privilege that is explicitly granted via the
<codeph>GRANT</codeph> statement and a privilege that is implicitly granted by the
<codeph>CREATE VIEW</codeph> statement.

246
docs/topics/impala_authorization.xml
View File

@@ -39,8 +39,8 @@ under the License.
<p>
Authorization determines which users are allowed to access which resources, and what
operations they are allowed to perform. You use Apache Sentry or Apache Ranger for
authorization. By default, when authorization is not enabled, Impala does all read and
operations they are allowed to perform. You use Apache Ranger for authorization.
By default, when authorization is not enabled, Impala does all read and
write operations with the privileges of the <codeph>impala</codeph> user, which is
suitable for a development/test environment but not for a secure production environment.
When authorization is enabled, Impala uses the OS user ID of the user who runs
@@ -92,7 +92,7 @@ under the License.
<p>
Privileges are managed via the <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> SQL
statements that require the Sentry or Ranger service enabled.
statements that require the Ranger service enabled.
</p>
<p>
@@ -106,45 +106,6 @@ under the License.
</concept>
<concept id="object_ownership">
<title>Object Ownership in Sentry</title>
<conbody>
<p>
Impala supports the ownership on databases, tables, and views. The
<codeph>CREATE</codeph> statements implicitly make the user running the statement the
owner of the object. An owner has the <codeph>OWNER</codeph> privilege if enabled in
Sentry. For example, if <varname>User A</varname> creates a database,
<varname>foo</varname>, via the <codeph>CREATE DATABASE</codeph> statement,
<varname>User A</varname> now owns the <varname>foo</varname> database and is authorized
to perform any operation on the <varname>foo</varname> database.
</p>
<p>
The <codeph>OWNER</codeph> privilege is not a grantable or revokable privilege whereas
the <codeph>ALL</codeph> privilege is explicitly granted via the <codeph>GRANT</codeph>
statement.
</p>
<p>
The object ownership feature is controlled by a Sentry configuration. The
<codeph>OWNER</codeph> privilege is only granted when the feature is enabled in Sentry.
When enabled they get the owner privilege, with or without the <codeph>GRANT
OPTION</codeph>, which is also controlled by the Sentry configuration.
</p>
<p>
An ownership can be transferred to another user or role via the <codeph>ALTER
DATABASE</codeph>, <codeph>ALTER TABLE</codeph>, or <codeph>ALTER VIEW</codeph> with the
<codeph>SET OWNER</codeph> clause.
</p>
</conbody>
</concept>
<concept id="concept_fgf_smj_bjb">
<title>Object Ownership in Ranger</title>
@@ -188,50 +149,6 @@ under the License.
</concept>
<concept id="secure_startup">
<title>Starting Impala with Sentry Authorization Enabled</title>
<prolog>
<metadata>
<data name="Category" value="Starting and Stopping"/>
</metadata>
</prolog>
<conbody>
<p>
To enable authorization in an Impala cluster using Sentry:
<ol>
<li>
Add the following options to the <codeph>IMPALA_SERVER_ARGS</codeph> and the
<codeph>IMPALA_CATALOG_ARGS</codeph> settings in the
<filepath>/etc/default/impala</filepath> configuration file:
<ul>
<li>
<codeph>-server_name</codeph>: For all <cmdname>impalad</cmdname> nodes and the
<codeph>catalogd</codeph> in the cluster, specify the same name set in the
<codeph>sentry.hive.server</codeph> property in the
<filepath>sentry-site.xml</filepath> configuration file for Hive.
</li>
<li>
<codeph>-sentry_config</codeph>: Specifies the local path to the
<codeph>sentry-site.xml</codeph> configuration file.
</li>
</ul>
</li>
<li>
Restart the <codeph>catalogd</codeph> and all <cmdname>impalad</cmdname> daemons.
</li>
</ol>
</p>
</conbody>
</concept>
<concept id="enable_ranger_authz">
<title>Starting Impala with Ranger Authorization Enabled</title>
@@ -250,17 +167,12 @@ under the License.
<ul>
<li>
<codeph>-server_name</codeph>: Specify the same name for all
<cmdname>impalad</cmdname> nodes and the <codeph>catalogd</codeph> in the cluster.
</li>
<cmdname>impalad</cmdname> nodes and the <codeph>catalogd</codeph> in the cluster. </li>
<li>
<codeph>-ranger_service_type=hive</codeph>
</li>
<li>
<codeph>-ranger_app_id</codeph>: Set it to the Ranger application id.
</li>
<codeph>-ranger_app_id</codeph>: Set it to the Ranger application id. </li>
<li>
<codeph>-authorization_provider=ranger</codeph>
</li>
@@ -284,8 +196,7 @@ under the License.
<p>
You set up privileges through the <codeph>GRANT</codeph> and <codeph>REVOKE</codeph>
statements in either Impala or Hive. Then both components use those same privileges
automatically.
statements in either Impala or Hive.
</p>
<p>
@@ -305,18 +216,12 @@ under the License.
<conbody>
<p>
If you make a change to privileges in Sentry or Ranger from outside of Impala, e.g.
If you make a change to privileges in Ranger from outside of Impala, e.g.
adding a user, removing a user, modifying privileges, there are two options to
propagate the change:
</p>
<ul>
<li>
Use the <codeph>catalogd</codeph> flag,
<codeph>--sentry_catalog_polling_frequency_s</codeph> to specify how often to do a
Sentry refresh. The flag is set to 60 seconds by default.
</li>
<li>
Use the <codeph>ranger.plugin.hive.policy.pollIntervalMs</codeph> property to
specify how often to do a Ranger refresh. The property is specified in
@@ -397,60 +302,49 @@ GRANT ALL ON URI hdfs://namenode:port/path/to/dir TO &lt;role></codeblock>
<conbody>
<p>
The following examples show how to set up authorization to deal with various
scenarios.
The following examples show how to set up authorization to grant privileges on objects
to groups of users via roles.
</p>
<example>
<title>A User with No Privileges</title>
<p>
If a user has no privileges at all, that user cannot access any schema objects in
the system. The error messages do not disclose the names or existence of objects
that the user is not authorized to read.
If a user has no privileges at all, that user cannot access any schema objects in the
system. The error messages do not disclose the names or existence of objects that the
user is not authorized to read.
</p>
<p>
This is the experience you want a user to have if they somehow log into a system
where they are not an authorized Impala user. Or in a real deployment, a user might
have no privileges because they are not a member of any of the authorized groups.
This is the experience you want a user to have if they somehow log into a system where
they are not an authorized Impala user. Or in a real deployment, a user might have no
privileges because they are not a member of any of the authorized groups.
</p>
</example>
<example>
<title>Examples of Privileges for Administrative Users</title>
<p>
In this example, the SQL statements grant the <codeph>entire_server</codeph> role
all privileges on both the databases and URIs within the server.
In this example, the SQL statements grant the <codeph>entire_server</codeph> role all
privileges on both the databases and URIs within the server.
</p>
<codeblock>CREATE ROLE entire_server;
GRANT ROLE entire_server TO GROUP admin_group;
GRANT ALL ON SERVER server1 TO ROLE entire_server;
</codeblock>
</example>
<example>
<title>A User with Privileges for Specific Databases and Tables</title>
<p>
If a user has privileges for specific tables in specific databases, the user can
access those things but nothing else. They can see the tables and their parent
databases in the output of <codeph>SHOW TABLES</codeph> and <codeph>SHOW
DATABASES</codeph>, <codeph>USE</codeph> the appropriate databases, and perform the
relevant actions (<codeph>SELECT</codeph> and/or <codeph>INSERT</codeph>) based on
the table privileges. To actually create a table requires the <codeph>ALL</codeph>
privilege at the database level, so you might define separate roles for the user
that sets up a schema and other users or applications that perform day-to-day
operations on the tables.
access those things but nothing else. They can see the tables and their parent databases
in the output of <codeph>SHOW TABLES</codeph> and <codeph>SHOW DATABASES</codeph>,
<codeph>USE</codeph> the appropriate databases, and perform the relevant actions
(<codeph>SELECT</codeph> and/or <codeph>INSERT</codeph>) based on the table
privileges. To actually create a table requires the <codeph>ALL</codeph> privilege at
the database level, so you might define separate roles for the user that sets up a
schema and other users or applications that perform day-to-day operations on the tables.
</p>
<codeblock>
CREATE ROLE one_database;
GRANT ROLE one_database TO GROUP admin_group;
@@ -464,99 +358,67 @@ GRANT ALL ON TABLE db1.lesson TO ROLE instructor;
CREATE ROLE student;
GRANT ROLE student TO GROUP visitors;
GRANT SELECT ON TABLE db1.training TO ROLE student;</codeblock>
</example>
<example>
<title>Privileges for Working with External Data Files</title>
<p>
When data is being inserted through the <codeph>LOAD DATA</codeph> statement or is
<p> When data is being inserted through the <codeph>LOAD DATA</codeph> statement or is
referenced from an HDFS location outside the normal Impala database directories, the
user also needs appropriate permissions on the URIs corresponding to those HDFS
locations.
</p>
<p>
In this example:
</p>
locations. </p>
<p> In this example: </p>
<ul>
<li>
The <codeph>external_table</codeph> role can insert into and query the Impala
table, <codeph>external_table.sample</codeph>.
</li>
<li> The <codeph>external_table</codeph> role can insert into and query the Impala
table, <codeph>external_table.sample</codeph>. </li>
<li>
The <codeph>staging_dir</codeph> role can specify the HDFS path
<filepath>/user/impala-user/external_data</filepath> with the <codeph>LOAD
DATA</codeph> statement. When Impala queries or loads data files, it operates on
all the files in that directory, not just a single file, so any Impala
<codeph>LOCATION</codeph> parameters refer to a directory rather than an
individual file.
</li>
<li> The <codeph>staging_dir</codeph> role can specify the HDFS path
<filepath>/user/impala-user/external_data</filepath> with the <codeph>LOAD
DATA</codeph> statement. When Impala queries or loads data files, it operates on all
the files in that directory, not just a single file, so any Impala
<codeph>LOCATION</codeph> parameters refer to a directory rather than an individual
file. </li>
</ul>
<codeblock>CREATE ROLE external_table;
<codeblock>CREATE ROLE external_table;
GRANT ROLE external_table TO GROUP impala_users;
GRANT ALL ON TABLE external_table.sample TO ROLE external_table;
CREATE ROLE staging_dir;
GRANT ROLE staging TO GROUP impala_users;
GRANT ALL ON URI 'hdfs://127.0.0.1:8020/user/impala-user/external_data' TO ROLE staging_dir;</codeblock>
</example>
<example>
<title>Separating Administrator Responsibility from Read and Write Privileges</title>
<p>
To create a database, you need the full privilege on that database while day-to-day
<p> To create a database, you need the full privilege on that database while day-to-day
operations on tables within that database can be performed with lower levels of
privilege on a specific table. Thus, you might set up separate roles for each
database or application: an administrative one that could create or drop the
database, and a user-level one that can access only the relevant tables.
</p>
<p>
In this example, the responsibilities are divided between users in 3 different
groups:
</p>
privilege on a specific table. Thus, you might set up separate roles for each database
or application: an administrative one that could create or drop the database, and a
user-level one that can access only the relevant tables. </p>
<p> In this example, the responsibilities are divided between users in 3 different groups: </p>
<ul>
<li>
Members of the <codeph>supergroup</codeph> group have the
<codeph>training_sysadmin</codeph> role and so can set up a database named
<codeph>training</codeph>.
</li>
<li> Members of the <codeph>supergroup</codeph> group have the
<codeph>training_sysadmin</codeph> role and so can set up a database named
<codeph>training</codeph>. </li>
<li>
Members of the <codeph>impala_users</codeph> group have the
<codeph>instructor</codeph> role and so can create, insert into, and query any
<li> Members of the <codeph>impala_users</codeph> group have the
<codeph>instructor</codeph> role and so can create, insert into, and query any
tables in the <codeph>training</codeph> database, but cannot create or drop the
database itself.
</li>
database itself. </li>
<li>
Members of the <codeph>visitor</codeph> group have the <codeph>student</codeph>
role and so can query those tables in the <codeph>training</codeph> database.
</li>
<li> Members of the <codeph>visitor</codeph> group have the <codeph>student</codeph>
role and so can query those tables in the <codeph>training</codeph> database. </li>
</ul>
<codeblock>CREATE ROLE training_sysadmin;
<codeblock>CREATE ROLE training_sysadmin;
GRANT ROLE training_sysadmin TO GROUP supergroup;
GRANT ALL ON DATABASE training1 TO ROLE training_sysadmin;
GRANT ALL ON DATABASE training TO ROLE training_sysadmin;
CREATE ROLE instructor;
GRANT ROLE instructor TO GROUP impala_users;
GRANT ALL ON TABLE training1.course1 TO ROLE instructor;
GRANT ALL ON TABLE training.course1 TO ROLE instructor;
CREATE ROLE visitor;
CREATE ROLE student;
GRANT ROLE student TO GROUP visitor;
GRANT SELECT ON TABLE training1.course1 TO ROLE student;</codeblock>
GRANT SELECT ON TABLE training.course1 TO ROLE student;</codeblock>
</example>
</conbody>

10
docs/topics/impala_create_role.xml
View File

@@ -45,8 +45,7 @@ under the License.
The <codeph>CREATE ROLE</codeph> 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 <codeph>hive</codeph>, <codeph>impala</codeph> and <codeph>hue</codeph> users have
administrative privileges in Sentry.
roles.
</p>
<p conref="../shared/impala_common.xml#common/syntax_blurb"/>
@@ -57,8 +56,7 @@ under the License.
<p conref="../shared/impala_common.xml#common/privileges_blurb"/>
<p>
Only administrative users (those with <codeph>ALL</codeph> privileges on the server, defined in the Sentry
policy file) can use this statement.
Only administrative users for Ranger can use this statement.
</p>
<p conref="../shared/impala_common.xml#common/compatibility_blurb"/>
@@ -66,9 +64,7 @@ under the License.
<p>
Impala makes use of any roles and privileges specified by the <codeph>GRANT</codeph> and
<codeph>REVOKE</codeph> statements in Hive, and Hive makes use of any roles and privileges specified by the
<codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements in Impala. The Impala <codeph>GRANT</codeph>
and <codeph>REVOKE</codeph> statements for privileges do not require the <codeph>ROLE</codeph> keyword to be
repeated before each role name, unlike the equivalent Hive statements.
<codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements in Impala.
</p>
<!-- To do: nail down the new SHOW syntax, e.g. SHOW ROLES, SHOW CURRENT ROLES, SHOW GROUPS. -->

7
docs/topics/impala_delegation.xml
View File

@@ -73,10 +73,7 @@ under the License.
</li>
<li>
Impala requires Apache Sentry on the cluster to enable delegation. Without Apache
Sentry installed, the delegation feature will fail with the following error: User
<i>user1</i> is not authorized to delegate to <i>user2</i>. User/group delegation is
disabled.
Impala requires Apache Ranger on the cluster to enable delegation.
</li>
</ul>
</note>
@@ -222,7 +219,7 @@ under the License.
</li>
<li>
In group delegate, Impala checks if <varname>delegated_user</varname> belongs to
In group delegation, Impala checks if <varname>delegated_user</varname> belongs to
one of the delegated groups for the user <varname>authenticated_user</varname>,
<varname>delegated_group</varname> in this example.
</li>

3
docs/topics/impala_drop_role.xml
View File

@@ -57,8 +57,7 @@ under the License.
<p conref="../shared/impala_common.xml#common/privileges_blurb"/>
<p>
Only administrative users (initially, a predefined set of users specified in the Sentry service configuration
file) can use this statement.
Only administrative users for Ranger can use this statement.
</p>
<p conref="../shared/impala_common.xml#common/compatibility_blurb"/>

53
docs/topics/impala_grant.xml
View File

@@ -53,28 +53,29 @@ under the License.
<p conref="../shared/impala_common.xml#common/syntax_blurb"/>
<p>
The following syntax is supported when Impala is using Sentry to manage authorization.
The following syntax are supported in Impala through Ranger to manage authorization.
</p>
<codeblock rev="2.3.0 collevelauth">GRANT ROLE <varname>role_name</varname> TO GROUP <varname>group_name</varname>
GRANT <varname>privilege</varname> ON <varname>object_type</varname> <varname>object_name</varname>
TO [ROLE] <varname>role_name</varname>
[WITH GRANT OPTION]
<ph id="privileges" rev="3.0"><varname>privilege</varname> ::= ALL | ALTER | CREATE | DROP | INSERT | REFRESH | SELECT | SELECT(<varname>column_name</varname>)</ph>
<ph id="priv_objs" rev="3.0"><varname>object_type</varname> ::= SERVER | URI | DATABASE | TABLE</ph>
</codeblock>
<p><b><codeph>GRANT ROLE TO GROUP</codeph></b></p>
<p>
The following syntax is supported when Impala is using Ranger to manage authorization.
For <codeph>GRANT ROLE TO GROUP</codeph>, only Ranger administrative users can grant roles to a group.
</p>
<codeblock>GRANT ROLE <varname>role_name</varname> TO GROUP <varname>group_name</varname></codeblock>
<p><b><codeph>GRANT privilege ON object TO PRINCIPAL</codeph></b></p>
<p>
For GRANT privilege ON object TO principal (a user, a group, or a role), Ranger
administrative users can use this statement. If the privilege is granted with the clause of
WITH GRANT OPTION, the grantee (the user, the users belonging to the group, or the users
belonging to the group granted the role) is able to grant the privilege to other principals.
</p>
<codeblock>GRANT <varname>privilege</varname> ON <varname>object_type</varname> <varname>object_name</varname>
TO USER <varname>user_name</varname>
GRANT <varname>privilege</varname> ON <varname>object_type</varname> <varname>object_name</varname>
TO GROUP <varname>group_name</varname>
GRANT <varname>privilege</varname> ON <varname>object_type</varname> <varname>object_name</varname>
TO ROLE <varname>role_name</varname>
<ph rev="3.0">privilege ::= ALL | ALTER | CREATE | DROP | INSERT | REFRESH | SELECT | SELECT(<varname>column_name</varname>)</ph>
<ph rev="3.0">object_type ::= SERVER | URI | DATABASE | TABLE</ph></codeblock>
@@ -86,19 +87,18 @@ GRANT <varname>privilege</varname> ON <varname>object_type</varname> <varname>ob
<p conref="../shared/impala_common.xml#common/privileges_blurb"/>
<p>
Only administrative users (initially, a predefined set of users specified in the Sentry
service configuration file) can use this statement.
Only administrative users for Ranger can use this statement.
</p>
<p>
Only Sentry administrative users can grant roles to a group.
Only Ranger administrative users can grant roles to a group.
</p>
<p>
The <codeph>WITH GRANT OPTION</codeph> clause allows members of the specified role to
issue <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements for those same
privileges. Hence, if a role has the <codeph>ALL</codeph> privilege on a database and the
<codeph>WITH GRANT OPTION</codeph> set, users granted that role can execute
The <codeph>WITH GRANT OPTION</codeph> clause allows members of the specified role to issue
<codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements for those same privileges.
Hence, if a role has the <codeph>ALL</codeph> privilege on a database and the <codeph>WITH
GRANT OPTION</codeph> set, users granted that role can execute
<codeph>GRANT</codeph>/<codeph>REVOKE</codeph> statements only for that database or child
tables of the database. This means a user could revoke the privileges of the user that
provided them the <codeph>GRANT OPTION</codeph>.
@@ -132,16 +132,9 @@ GRANT <varname>privilege</varname> ON <varname>object_type</varname> <varname>ob
</li>
<li>
In <keyword keyref="impala14_full"/> and later, Impala can make use of any roles and
privileges specified by the <codeph>GRANT</codeph> and <codeph>REVOKE</codeph>
statements in Hive, when your system is configured to use the Sentry service instead
of the file-based policy mechanism.
</li>
<li>
The Impala <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements for
privileges do not require the <codeph>ROLE</codeph> keyword to be repeated before each
role name, unlike the equivalent Hive statements.
In general, Impala can make use of any roles and privileges specified by the
<codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements in Hive, when your system
is configured to use the Ranger service instead of the file-based policy mechanism.
</li>
<li conref="../shared/impala_common.xml#common/grant_revoke_single"/>

4
docs/topics/impala_insert.xml
View File

@@ -513,8 +513,8 @@ Inserted 2 rows in 0.16s
</p>
<p>
The permission requirement is independent of the authorization performed by the Sentry framework. (If the
connected user is not authorized to insert into a table, Sentry blocks that operation immediately,
The permission requirement is independent of the authorization performed by the Ranger framework. (If the
connected user is not authorized to insert into a table, Ranger blocks that operation immediately,
regardless of the privileges available to the <codeph>impala</codeph> user.) Files created by Impala are
not owned by and do not inherit permissions from the connected user.
</p>

2
docs/topics/impala_invalidate_metadata.xml
View File

@@ -67,7 +67,7 @@ under the License.
</li>
<li>
The <codeph>SERVER</codeph> or <codeph>DATABASE</codeph> level Sentry privileges are
The <codeph>SERVER</codeph> or <codeph>DATABASE</codeph> level Ranger privileges are
changed.
</li>

2
docs/topics/impala_kudu.xml
View File

@@ -1348,7 +1348,7 @@ kudu.table_name | impala::some_database.table_name_demo
<ul>
<li>
<p>
Sentry authorization.
Ranger authorization.
</p>
<p conref="../shared/impala_common.xml#common/kudu_sentry_limitations"/>
</li>

8
docs/topics/impala_langref_unsupported.xml
View File

@@ -209,12 +209,12 @@ under the License.
<p>
Impala utilizes the <xref keyref="sentry">Apache
Sentry </xref> authorization framework, which provides fine-grained role-based access control
Ranger </xref> authorization framework, which provides fine-grained role-based access control
to protect data against unauthorized access or tampering.
</p>
<p>
The Hive component now includes Sentry-enabled <codeph>GRANT</codeph>,
The Hive component now includes Ranger-enabled <codeph>GRANT</codeph>,
<codeph>REVOKE</codeph>, and <codeph>CREATE/DROP ROLE</codeph> statements. Earlier Hive releases had a
privilege system with <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements that were primarily
intended to prevent accidental deletion of data, rather than a security mechanism to protect against
@@ -224,9 +224,7 @@ under the License.
<p>
Impala can make use of privileges set up through Hive <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements.
Impala has its own <codeph>GRANT</codeph> and <codeph>REVOKE</codeph> statements in Impala 2.0 and higher.
See <xref href="impala_authorization.xml#authorization"/> for the details of authorization in Impala, including
how to switch from the original policy file-based privilege model to the Sentry service using privileges
stored in the metastore database.
See <xref href="impala_authorization.xml#authorization"/> for the details of authorization in Impala.
</p>
<p>

2
docs/topics/impala_ldap.xml
View File

@@ -246,7 +246,7 @@ under the License.
<p>
When Impala connects to LDAP it issues a bind call to the LDAP server to authenticate as
the connected user. Impala clients, including the Impala shell, provide the short name
of the user to Impala. This is necessary so that Impala can use Sentry for role-based
of the user to Impala. This is necessary so that Impala can use Ranger for role-based
access, which uses short names.
</p>

2
docs/topics/impala_lineage.xml
View File

@@ -81,7 +81,7 @@ under the License.
<p>
When you have tables where you need to track or control access to sensitive information at the column
level, see <xref href="impala_authorization.xml#authorization"/> for how to implement column-level
security. You set up authorization using the Sentry framework, create views that refer to specific sets of
security. You set up authorization using the Ranger framework, create views that refer to specific sets of
columns, and then assign authorization privileges to those views rather than the underlying tables.
</p>

4
docs/topics/impala_logging.xml
View File

@@ -356,8 +356,8 @@ I0107 08:42:12.292706 14876 logging.cc:76] Flags (see also /varz are on debug we
or tax IDs, and literals matching these patterns are obfuscated wherever they would normally
be recorded in log files or displayed in administration or debugging user interfaces. </p>
<p> In a security context, the log redaction feature is complementary to the Sentry
authorization framework. Sentry prevents unauthorized users from being able to directly
<p> In a security context, the log redaction feature is complementary to the Ranger
authorization framework. Ranger prevents unauthorized users from being able to directly
access table data. Redaction prevents administrators or support personnel from seeing the
smaller amounts of sensitive or personally identifying information (PII) that might appear
in queries issued by those authorized users. </p>

2
docs/topics/impala_refresh.xml
View File

@@ -185,7 +185,7 @@ ERROR: AnalysisException: Items in partition spec must exactly match the partiti
<p conref="../shared/impala_common.xml#common/permissions_blurb"/>
<p rev="IMPALA-1683">
All HDFS and Sentry permissions and privilege requirements are the same whether you
All HDFS and Ranger permissions and privilege requirements are the same whether you
refresh the entire table or a single partition.
</p>

2
docs/topics/impala_refresh_authorization.xml
View File

@@ -43,7 +43,7 @@ under the License.
The <codeph>REFRESH AUTHORIZATION</codeph> statement explicitly refreshes authorization
data, including privileges and principals. When there is an external update to
authorization metadata, use this statement to force Impala to refresh its authorization
data without having to wait for the Sentry polling or run <codeph>INVALIDATE
data without having to wait for the Ranger polling or run <codeph>INVALIDATE
METADATA</codeph>.
</p>

33
docs/topics/impala_revoke.xml
View File

@@ -52,29 +52,20 @@ under the License.
<p conref="../shared/impala_common.xml#common/syntax_blurb"/>
<p>
The following syntax is supported when Impala is using Senty to manage authorization.
</p>
<codeblock rev="2.3.0 collevelauth">REVOKE ROLE <varname>role_name</varname> FROM GROUP <varname>group_name</varname>
REVOKE [GRANT OPTION FOR] <varname>privilege</varname> ON <varname>object_type</varname> <varname>object_name</varname>
FROM [ROLE] <varname>role_name</varname>
<ph rev="3.0">
<varname>privilege</varname> ::= ALL | ALTER | CREATE | DROP | INSERT | REFRESH | SELECT | SELECT(<varname>column_name</varname>)
</ph>
<ph id="priv_objs" rev="3.0"><varname>object_type</varname> ::= SERVER | URI | DATABASE | TABLE</ph></codeblock>
<p>
The following syntax is supported when Impala is using Ranger to manage authorization.
</p>
<codeblock>REVOKE <varname>privilege</varname> ON <varname>object_type</varname> <varname>object_name</varname>
<codeblock>REVOKE ROLE <varname>role_name</varname> FROM GROUP <varname>group_name</varname>
REVOKE <varname>privilege</varname> ON <varname>object_type</varname> <varname>object_name</varname>
FROM USER <varname>user_name</varname>
REVOKE <varname>privilege</varname> ON <varname>object_type</varname> <varname>object_name</varname>
FROM GROUP <varname>group_name</varname>
REVOKE [GRANT OPTION FOR] <varname>privilege</varname> ON <varname>object_type</varname> <varname>object_name</varname>
FROM [ROLE] <varname>role_name</varname>
<ph rev="3.0">
privilege ::= ALL | ALTER | CREATE | DROP | INSERT | REFRESH | SELECT | SELECT(<varname>column_name</varname>)
@@ -125,12 +116,11 @@ REVOKE ALL ON SERVER FROM ROLE foo_role;</codeblock>
<p conref="../shared/impala_common.xml#common/privileges_blurb"/>
<p>
Only administrative users (those with <codeph>ALL</codeph> privileges on the server,
defined in the Sentry policy file) can use this statement.
Only administrative users for Ranger can use this statement.
</p>
<p>
Only Sentry administrative users can revoke the role from a group.
Only Ranger administrative users can revoke the role from a group.
</p>
<p conref="../shared/impala_common.xml#common/compatibility_blurb"/>
@@ -144,10 +134,9 @@ REVOKE ALL ON SERVER FROM ROLE foo_role;</codeblock>
</li>
<li>
In <keyword keyref="impala14_full"/> and higher, Impala makes use of any roles and
privileges specified by the <codeph>GRANT</codeph> and <codeph>REVOKE</codeph>
statements in Hive, when your system is configured to use the Sentry service instead
of the file-based policy mechanism.
Impala makes use of any roles and privileges specified by the <codeph>GRANT</codeph>
and <codeph>REVOKE</codeph> statements in Hive, when your system is configured to use the
Ranger service instead of the file-based policy mechanism.
</li>
<li>

2
docs/topics/impala_scaling_limits.xml
View File

@@ -215,7 +215,7 @@ under the License.
<ul>
<li>
Number of roles: 10,000 for Sentry
Number of roles: 10,000 for Ranger
</li>
<li audience="hidden">

10
docs/topics/impala_security.xml
View File

@@ -37,9 +37,9 @@ under the License.
<conbody>
<p>
Impala includes a fine-grained authorization framework for Hadoop, based on Apache Sentry.
Sentry authorization was added in Impala 1.1.0. Together with the Kerberos
authentication framework, Sentry takes Hadoop security to a new level needed for the requirements of
Impala includes a fine-grained authorization framework for Hadoop, based on Apache Ranger.
Ranger authorization was added in Impala 3.3.0. Together with the Kerberos
authentication framework, Ranger takes Hadoop security to a new level needed for the requirements of
highly regulated industries such as healthcare, financial services, and government. Impala also includes
an auditing capability which was added in Impala 1.1.1; Impala generates the audit data which can be
consumed, filtered, and visualized by cluster-management components focused on governance.
@@ -78,7 +78,7 @@ under the License.
<dd>
Which users are allowed to access which resources, and what operations are they allowed to perform?
Impala relies on the open source Sentry project for authorization. By default (when authorization is not
Impala relies on the open source Ranger project for authorization. By default (when authorization is not
enabled), Impala does all read and write operations with the privileges of the <codeph>impala</codeph>
user, which is suitable for a development/test environment but not for a secure production environment.
When authorization is enabled, Impala uses the OS user ID of the user who runs
@@ -125,7 +125,7 @@ under the License.
<p audience="integrated">
These other topics in the <cite>Security Guide</cite> cover how Impala integrates with security frameworks
such as Kerberos, LDAP, and Sentry:
such as Kerberos, LDAP, and Ranger:
<ul>
<li>
<xref href="impala_authentication.xml#authentication"/>

2
docs/topics/impala_security_files.xml
View File

@@ -64,7 +64,7 @@ under the License.
<li>
<p>
The way to ensure that only authorized users can submit requests for databases and tables they are allowed
to access is to set up Sentry authorization, as explained in
to access is to set up Ranger authorization, as explained in
<xref href="impala_authorization.xml#authorization"/>. With authorization enabled, the checking of the user
ID and group is done by Impala, and unauthorized access is blocked by Impala itself. The actual low-level
read and write requests are still done by the <codeph>impala</codeph> user, so you must have appropriate

35
docs/topics/impala_show.xml
View File

@@ -52,23 +52,20 @@ SHOW FILES IN [<varname>database_name</varname>.]<varname>table_name</varname> <
SHOW CURRENT ROLES
SHOW ROLE GRANT GROUP <varname>group_name</varname></ph>
<ph rev="3.1.0">SHOW GRANT USER <varname>user_name</varname> ON SERVER
<ph rev="3.1.0">SHOW GRANT USER <varname>user_name</varname>
SHOW GRANT USER <varname>user_name</varname> ON SERVER
SHOW GRANT USER <varname>user_name</varname> ON DATABASE <varname>database_name</varname>
SHOW GRANT USER <varname>user_name</varname> ON TABLE <varname>database_name.table_name</varname>
SHOW GRANT USER <varname>user_name</varname> ON URI <varname>uri</varname></ph>
SHOW GRANT USER <varname>user_name</varname> ON COLUMN <varname>database_name.table_name.column_name</varname></codeblock>
<p>The following statements are supported only when Impala uses Sentry to
manage authorization.</p>
<codeblock>SHOW GRANT USER <varname>user_name</varname>
SHOW GRANT ROLE <varname>role_name</varname>
<codeblock>SHOW GRANT ROLE <varname>role_name</varname>
SHOW GRANT ROLE <varname>role_name</varname> ON SERVER
SHOW GRANT ROLE <varname>role_name</varname> ON DATABASE <varname>database_name</varname>
SHOW GRANT ROLE <varname>role_name</varname> ON TABLE <varname>database_name.table_name</varname>
SHOW GRANT ROLE <varname>role_name</varname> ON URI <varname>uri</varname>
SHOW GRANT ROLE <varname>role_name</varname> ON COLUMN <varname>database_name.table_name.column_name</varname></codeblock>
<p rev="3.3">The following statements are supported only when Impala uses
Ranger to manage authorization.</p>
<codeblock>SHOW GRANT GROUP <varname>group_name</varname> ON SERVER
SHOW GRANT GROUP <varname>group_name</varname> ON DATABASE <varname>database_name</varname>
SHOW GRANT GROUP <varname>group_name</varname> ON TABLE <varname>database_name.table_name</varname>
@@ -336,7 +333,7 @@ where id between 1 and 1000000;
<p>
The <codeph>SHOW ROLES</codeph> statement displays roles. This syntax
is available in <keyword keyref="impala20_full"/> and later only, when
you are using the Sentry authorization framework along with the Sentry
you are using the Ranger authorization framework along with the Ranger
service, as described in <xref
href="impala_authorization.xml#sentry_service"/>.
</p>
@@ -389,8 +386,8 @@ where id between 1 and 1000000;
<p rev="2.0.0">
The <codeph>SHOW CURRENT ROLES</codeph> statement displays
roles assigned to the current user. This syntax is available in <keyword
keyref="impala20_full"/> and later only, when you are using the Sentry
authorization framework along with the Sentry service, as described in
keyref="impala20_full"/> and later only, when you are using the Ranger
authorization framework along with the Ranger service, as described in
<xref href="impala_authorization.xml#sentry_service"/>.
</p>
@@ -440,10 +437,10 @@ where id between 1 and 1000000;
<p rev="2.0.0">
The <codeph>SHOW ROLE GRANT GROUP</codeph> statement lists
all the roles assigned to the specified group. This statement is only
allowed for Sentry administrative users and others users that are part
allowed for Ranger administrative users and others users that are part
of the specified group. This syntax is available in <keyword
keyref="impala20_full"/> and later only, when you are using the Sentry
authorization framework along with the Sentry service, as described in
keyref="impala20_full"/> and later only, when you are using the Ranger
authorization framework along with the Ranger service, as described in
<xref href="impala_authorization.xml#sentry_service"/>.
</p>
@@ -477,11 +474,11 @@ where id between 1 and 1000000;
<p>
<!-- Copied from Sentry docs. Turn into conref. I did some rewording for clarity. -->
The <codeph>SHOW GRANT ROLE</codeph> statement list all the grants for
the given role name. This statement is only allowed for Sentry
the given role name. This statement is only allowed for Ranger
administrative users and other users that have been granted the
specified role. This syntax is available in <keyword
keyref="impala20_full"/> and later only, when you are using the Sentry
authorization framework along with the Sentry service, as described in
keyref="impala20_full"/> and later only, when you are using the Ranger
authorization framework along with the Ranger service, as described in
<xref href="impala_authorization.xml#sentry_service"/>.
</p>
@@ -514,14 +511,14 @@ where id between 1 and 1000000;
<conbody>
<p>
The <codeph>SHOW GRANT USER</codeph> statement shows the list of
privileges for a given user. This statement is only allowed for Sentry
privileges for a given user. This statement is only allowed for Ranger
administrative users. However, the current user can run <codeph>SHOW
GRANT USER</codeph> for themselves.
</p>
<p>
This syntax is available in <keyword keyref="impala31_full"/> and later
only, when you are using the Sentry authorization framework along with
the Sentry service, as described in <xref
only, when you are using the Ranger authorization framework along with
the Ranger service, as described in <xref
href="impala_authorization.xml#sentry_service"/>.
</p>
<p conref="../shared/impala_common.xml#common/security_blurb"/>

2
docs/topics/impala_ssl.xml
View File

@@ -38,7 +38,7 @@ under the License.
<p>
Impala supports TLS/SSL network encryption, between Impala and client programs, and
between the Impala-related daemons running on different nodes in the cluster. This feature
is important when you also use other features such as Kerberos authentication or Sentry
is important when you also use other features such as Kerberos authentication or Ranger
authorization, where credentials are being transmitted back and forth.
</p>