You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@impala.apache.org by ar...@apache.org on 2019/05/06 23:25:20 UTC
[impala] branch master updated: IMPALA-8364: [DOCS] Remove
refereces to authz policy files
This is an automated email from the ASF dual-hosted git repository.
arodoni pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/impala.git
The following commit(s) were added to refs/heads/master by this push:
new ae7aefe IMPALA-8364: [DOCS] Remove refereces to authz policy files
ae7aefe is described below
commit ae7aefe34cc3a88f8a7650312b8a2ac9dc6a348e
Author: Alex Rodoni <ar...@cloudera.com>
AuthorDate: Fri May 3 15:55:07 2019 -0700
IMPALA-8364: [DOCS] Remove refereces to authz policy files
Change-Id: Ic85a74d81142803894d30c99cea0ec8a516bf756
Reviewed-on: http://gerrit.cloudera.org:8080/13235
Tested-by: Impala Public Jenkins <im...@cloudera.com>
Reviewed-by: Fredy Wijaya <fw...@cloudera.com>
---
docs/topics/impala_authorization.xml | 286 ++---------------------------------
docs/topics/impala_grant.xml | 9 +-
docs/topics/impala_revoke.xml | 9 +-
docs/topics/impala_show.xml | 61 ++++----
4 files changed, 54 insertions(+), 311 deletions(-)
diff --git a/docs/topics/impala_authorization.xml b/docs/topics/impala_authorization.xml
index 33363a3..a2b7399 100644
--- a/docs/topics/impala_authorization.xml
+++ b/docs/topics/impala_authorization.xml
@@ -99,45 +99,16 @@ under the License.
<p conref="../shared/impala_common.xml#common/sentry_privileges_objects"/>
- <p>
- 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 <codeph>GRANT</codeph> and
- <codeph>REVOKE</codeph> 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.
- </p>
-
- <note>
- <p>
- Although this document refers to the <codeph>ALL</codeph> privilege, currently if you
- use the policy file mode, you do not use the actual keyword <codeph>ALL</codeph> in
- the policy file. When you code role entries in the policy file:
- </p>
- <ul>
- <li>
- To specify the <codeph>ALL</codeph> privilege for a server, use a role like
- <codeph>server=<varname>server_name</varname></codeph>.
- </li>
+ <p> Privileges are managed via the <codeph>GRANT</codeph> and
+ <codeph>REVOKE</codeph> SQL statements that requires the Sentry
+ service enabled. The Sentry service stores, retrieves, and manipulates
+ privilege information stored inside the Sentry database. </p>
- <li>
- To specify the <codeph>ALL</codeph> privilege for a database, use a role like
- <codeph>server=<varname>server_name</varname>->db=<varname>database_name</varname></codeph>.
- </li>
-
- <li>
- To specify the <codeph>ALL</codeph> privilege for a table, use a role like
- <codeph>server=<varname>server_name</varname>->db=<varname>database_name</varname>->table=<varname>table_name</varname>->action=*</codeph>.
- </li>
- </ul>
- </note>
-
- <p>
- 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
- <codeph>INVALIDATE METADATA</codeph> statement. <codeph>INVALIDATE METADATA</codeph> is
- not required if you make the changes to privileges within Impala.
- </p>
+ <p> If you change privileges outside of Impala, e.g. adding a user,
+ removing a user, modifying privileges, you must clear the Impala Catalog
+ server cache by running the <codeph>REFRESH AUTHORIZATION</codeph>
+ statement. <codeph>REFRESH AUTHORIZATION</codeph> is not required if you
+ make the changes to privileges within Impala. </p>
</conbody>
@@ -167,11 +138,6 @@ under the License.
authorization rules refer to a symbolic server name, and you specify the same name to
use as the argument to the <codeph>-server_name</codeph> option for all
<cmdname>impalad</cmdname> nodes in the cluster.
- <p>
- Starting in Impala 1.4.0 and higher, if you specify just
- <codeph>-server_name</codeph> without <codeph>-authorization_policy_file</codeph>,
- Impala uses the Sentry service for authorization.
- </p>
</li>
<li>
@@ -179,20 +145,11 @@ under the License.
<codeph>sentry-site.xml</codeph> configuration file. This setting is required to
enable authorization.
</li>
-
- <li>
- <codeph>-authorization_policy_file</codeph>: Specifies the HDFS path to the policy
- file that defines the privileges on schema objects. Prior to Impala 1.4.0, or if you
- want to continue storing privilege rules in the policy file, specify the
- <codeph>-authorization_policy_file</codeph> option to make Impala read privilege
- information from a policy file, rather than from the metastore database.
- </li>
</ul>
<p rev="1.4.0">
For example, you might adapt your <filepath>/etc/default/impala</filepath> configuration
- to contain lines like the following. To use the Sentry service rather than the policy
- file:
+ to contain lines like the following. To use the Sentry service:
</p>
<codeblock rev="1.4.0">IMPALA_SERVER_ARGS=" \
@@ -201,16 +158,6 @@ under the License.
</codeblock>
<p>
- Or to use the policy file, as in releases prior to Impala 1.4:
- </p>
-
-<codeblock>IMPALA_SERVER_ARGS=" \
--authorization_policy_file=/user/hive/warehouse/auth-policy.ini \
--server_name=server1 \
-...
-</codeblock>
-
- <p>
The preceding examples set up a symbolic name of <codeph>server1</codeph> to refer to
the current instance of Impala. Specify the symbolic name for the
<codeph>sentry.hive.server</codeph> property in the <filepath>sentry-site.xml</filepath>
@@ -512,198 +459,6 @@ GRANT SELECT ON TABLE training1.course1 TO ROLE student;</codeblock>
</concept>
- <concept id="security_policy_file">
-
- <title>Using Impala with the Sentry Policy File</title>
-
- <conbody>
-
- <p>
- The policy file is a file that you put in a designated location in HDFS, and is read
- during the startup of the <cmdname>impalad</cmdname> daemon when you specify both the
- <codeph>-server_name</codeph> and <codeph>-authorization_policy_file</codeph> startup
- options. It controls which objects (databases, tables, and HDFS directory paths) can be
- accessed by the user who connects to <cmdname>impalad</cmdname>, and what operations
- that user can perform on the objects.
- </p>
-
- <note rev="1.4.0">
- The policy-file based authorization was deprecated in <keyword keyref="impala26"/>. We
- recommend managing privileges through SQL statements as described in
- <xref
- href="impala_authorization.xml#sentry_service"/>. If you are still using
- policy files, plan to migrate to the new approach some time in the future.
- </note>
-
- <p>
- The location of the policy file is listed in the <filepath>auth-site.xml</filepath>
- configuration file.
- </p>
-
- <p>
- When authorization is enabled, Impala uses the policy file as a <i>whitelist</i>,
- 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.
- </p>
-
- <p>
- 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 <codeph>SHOW DATABASES</codeph>, and an
- error when you issue any <codeph>SHOW TABLES</codeph>, <codeph>USE
- <varname>database_name</varname></codeph>, <codeph>DESCRIBE
- <varname>table_name</varname></codeph>, <codeph>SELECT</codeph>, and or other statements
- that expect to access databases or tables, even if the corresponding databases and
- tables exist.
- </p>
-
- <p>
- The contents of the policy file are cached, to avoid a performance penalty for each
- query. The policy file is re-checked by each <cmdname>impalad</cmdname> 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
- <cmdname>impalad</cmdname> daemon on all nodes, again specifying the
- <codeph>-server_name</codeph> and <codeph>-authorization_policy_file</codeph> options so
- that the rules from the updated policy file are applied.
- </p>
-
- </conbody>
-
- <concept id="security_policy_file_details">
-
- <title>Policy File Format</title>
-
- <conbody>
-
- <p>
- The policy file uses the familiar <codeph>.ini</codeph> format, divided into the major
- sections <codeph>[groups]</codeph> and <codeph>[roles]</codeph>.
- </p>
-
- <p>
- There is also an optional <codeph>[databases]</codeph> section, which allows you to
- specify a specific policy file for a particular database, as explained in
- <xref href="#security_multiple_policy_files"
- />.
- </p>
-
- <p>
- Another optional section, <codeph>[users]</codeph>, allows you to override the
- OS-level mapping of users to groups; that is an advanced technique primarily for
- testing and debugging, and is beyond the scope of this document.
- </p>
-
- <p>
- In the <codeph>[groups]</codeph> section, you define various categories of users and
- select which roles are associated with each category. The group and usernames
- correspond to Linux groups and users on the server where the
- <cmdname>impalad</cmdname> daemon runs.
- </p>
-
- <p>
- The group and usernames in the <codeph>[groups]</codeph> section correspond to Hadoop
- groups and users on the server where the <cmdname>impalad</cmdname> daemon runs. When
- you access Impala through the <cmdname>impalad</cmdname> interpreter, for purposes of
- authorization, the user is the logged-in Linux user and the groups are the Linux
- groups that user is a member of. When you access Impala through the ODBC or JDBC
- interfaces, the user and password specified through the connection string are used as
- login credentials for the Linux server, and authorization is based on that username
- and the associated Linux group membership.
- </p>
-
- <p>
- In the <codeph>[roles]</codeph> section, you a set of roles. For each role, you
- specify precisely the set of privileges is available. That is, which objects users
- with that role can access, and what operations they can perform on those objects. This
- is the lowest-level category of security information; the other sections in the policy
- file map the privileges to higher-level divisions of groups and users. In the
- <codeph>[groups]</codeph> section, you specify which roles are associated with which
- groups. The group and usernames correspond to Linux groups and users on the server
- where the <cmdname>impalad</cmdname> daemon runs. The privileges are specified using
- patterns like:
-<codeblock>server=<varname>server_name</varname>->db=<varname>database_name</varname>->table=<varname>table_name</varname>->action=SELECT
-server=<varname>server_name</varname>->db=<varname>database_name</varname>->table=t<varname>able_name</varname>->action=CREATE
-server=<varname>server_name</varname>->db=<varname>database_name</varname>->table=<varname>table_name</varname>->action=ALL
-</codeblock>
- For the <varname>server_name</varname> value, substitute the same symbolic name you
- specify with the <cmdname>impalad</cmdname> <codeph>-server_name</codeph> option. You
- can use <codeph>*</codeph> wildcard characters at each level of the privilege
- specification to allow access to all such objects. For example:
-<codeblock>server=impala-host.example.com->db=default->table=t1->action=SELECT
-server=impala-host.example.com->db=*->table=*->action=CREATE
-server=impala-host.example.com->db=*->table=audit_log->action=SELECT
-server=impala-host.example.com->db=default->table=t1->action=*
-</codeblock>
- </p>
-
- </conbody>
-
- </concept>
-
- <concept id="security_multiple_policy_files">
-
- <title>Using Multiple Policy Files for Different Databases</title>
-
- <conbody>
-
- <p>
- For an Impala cluster with many databases being accessed by many users and
- applications, it might be cumbersome to update the security policy file for each
- privilege change or each new database, table, or view. You can allow security to be
- managed separately for individual databases, by setting up a separate policy file for
- each database:
- </p>
-
- <ul>
- <li>
- Add the optional <codeph>[databases]</codeph> section to the main policy file.
- </li>
-
- <li>
- Add entries in the <codeph>[databases]</codeph> section for each database that has
- its own policy file.
- </li>
-
- <li>
- For each listed database, specify the HDFS path of the appropriate policy file.
- </li>
- </ul>
-
- <p>
- For example:
- </p>
-
-<codeblock>[databases]
-# Defines the location of the per-DB policy files for the 'customers' and 'sales' databases.
-customers = hdfs://ha-nn-uri/etc/access/customers.ini
-sales = hdfs://ha-nn-uri/etc/access/sales.ini
-</codeblock>
-
- <p>
- To enable URIs in per-DB policy files, the Java configuration option
- <codeph>sentry.allow.uri.db.policyfile</codeph> must be set to <codeph>true</codeph>.
- For example:
- </p>
-
-<codeblock>JAVA_TOOL_OPTIONS="-Dsentry.allow.uri.db.policyfile=true"
-</codeblock>
-
- <note type="important">
- Enabling URIs in per-DB policy files introduces a security risk by allowing the owner
- of the db-level policy file to grant himself/herself load privileges to anything the
- <codeph>impala</codeph> user has read permissions for in HDFS (including data in other
- databases controlled by different db-level policy files).
- </note>
-
- </conbody>
-
- </concept>
-
- </concept>
-
<concept id="security_schema">
<title>Setting Up Schema Objects for a Secure Impala Deployment</title>
@@ -727,19 +482,6 @@ sales = hdfs://ha-nn-uri/etc/access/sales.ini
</concept>
- <concept id="sentry_debug">
-
- <title><ph conref="../shared/impala_common.xml#common/title_sentry_debug"
- /></title>
-
- <conbody>
-
- <p conref="../shared/impala_common.xml#common/sentry_debug"/>
-
- </conbody>
-
- </concept>
-
<concept id="sec_ex_default">
<title>The DEFAULT Database in a Secure Deployment</title>
@@ -749,10 +491,10 @@ sales = hdfs://ha-nn-uri/etc/access/sales.ini
<p>
Because of the extra emphasis on granular access controls in a secure deployment, you
should move any important or sensitive information out of the <codeph>DEFAULT</codeph>
- database into a named database whose privileges are specified in the policy file.
- Sometimes you might need to give privileges on the <codeph>DEFAULT</codeph> database for
- administrative reasons; for example, as a place you can reliably specify with a
- <codeph>USE</codeph> statement when preparing to drop a database.
+ database into a named database. Sometimes you might need to give privileges on the
+ <codeph>DEFAULT</codeph> database for administrative reasons, for example, as a place
+ you can reliably specify with a <codeph>USE</codeph> statement when preparing to drop a
+ database.
</p>
</conbody>
diff --git a/docs/topics/impala_grant.xml b/docs/topics/impala_grant.xml
index fe23b4b..9100e56 100644
--- a/docs/topics/impala_grant.xml
+++ b/docs/topics/impala_grant.xml
@@ -71,12 +71,9 @@ 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.
- </p>
-
- <p>
- Only Sentry administrative users can grant roles to a group.
+ Only Sentry administrative users, users who belong to the groups defined
+ in <codeph>sentry.service.admin.group</codeph> of the Sentry configuration
+ can grant roles to a group.
</p>
<p>
diff --git a/docs/topics/impala_revoke.xml b/docs/topics/impala_revoke.xml
index 25992b1..9a1571d 100644
--- a/docs/topics/impala_revoke.xml
+++ b/docs/topics/impala_revoke.xml
@@ -106,12 +106,9 @@ 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.
- </p>
-
- <p>
- Only Sentry administrative users can revoke the role from a group.
+ Only Sentry administrative users, users who belong to the groups defined in
+ <codeph>sentry.service.admin.group</codeph> of the Sentry configuration can revoke a role
+ from a group.
</p>
<p conref="../shared/impala_common.xml#common/compatibility_blurb"/>
diff --git a/docs/topics/impala_show.xml b/docs/topics/impala_show.xml
index 86c280a..6b7bc87 100644
--- a/docs/topics/impala_show.xml
+++ b/docs/topics/impala_show.xml
@@ -334,10 +334,11 @@ where id between 1 and 1000000;
<conbody>
<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 service, as described in
- <xref href="impala_authorization.xml#sentry_service"/>. It does not apply when you use the Sentry framework
- with privileges defined in a policy file.
+ 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
+ service, as described in <xref
+ href="impala_authorization.xml#sentry_service"/>.
</p>
<p conref="../shared/impala_common.xml#common/security_blurb"/>
@@ -386,10 +387,11 @@ where id between 1 and 1000000;
<conbody>
<p rev="2.0.0">
- The <codeph>SHOW CURRENT ROLE</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 <xref href="impala_authorization.xml#sentry_service"/>. It does not
- apply when you use the Sentry framework with privileges defined in a policy file.
+ The <codeph>SHOW CURRENT ROLE</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
+ <xref href="impala_authorization.xml#sentry_service"/>.
</p>
<p conref="../shared/impala_common.xml#common/security_blurb"/>
@@ -436,13 +438,14 @@ where id between 1 and 1000000;
<conbody>
<p rev="2.0.0">
-<!-- Copied from Sentry docs. Turn into conref. I did some rewording for clarity. -->
- The <codeph>SHOW ROLE GRANT</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 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
- <xref href="impala_authorization.xml#sentry_service"/>. It does not apply when you use the Sentry framework
- with privileges defined in a policy file.
+ <!-- Copied from Sentry docs. Turn into conref. I did some rewording for clarity. -->
+ The <codeph>SHOW ROLE GRANT</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 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
+ <xref href="impala_authorization.xml#sentry_service"/>.
</p>
<p conref="../shared/impala_common.xml#common/security_blurb"/>
@@ -478,12 +481,14 @@ where id between 1 and 1000000;
<conbody>
<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 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 <xref href="impala_authorization.xml#sentry_service"/>. It
- does not apply when you use the Sentry framework with privileges defined in a policy file.
+ <!-- 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
+ 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
+ <xref href="impala_authorization.xml#sentry_service"/>.
</p>
<p conref="../shared/impala_common.xml#common/security_blurb"/>
@@ -513,16 +518,18 @@ where id between 1 and 1000000;
</metadata>
</prolog>
<conbody>
- <p> The <codeph>SHOW GRANT USER</codeph> statement shows the list of
+ <p>
+ The <codeph>SHOW GRANT USER</codeph> statement shows the list of
privileges for a given user. This statement is only allowed for Sentry
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
+ 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
- href="impala_authorization.xml#sentry_service"/>. It does not apply
- when you use the Sentry framework with privileges defined in a policy
- file. </p>
+ href="impala_authorization.xml#sentry_service"/>.
+ </p>
<p conref="../shared/impala_common.xml#common/security_blurb"/>
<p conref="../shared/impala_common.xml#common/show_security"/>
<p conref="../shared/impala_common.xml#common/permissions_blurb_no"/>