This is an automated email from the ASF dual-hosted git repository.
abukor pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/kudu.git
The following commit(s) were added to refs/heads/master by this push:
new 9602f77 [docs] Remove Sentry from documentation
9602f77 is described below
commit 9602f77fdf5057627101b19f18d41c48027cadbf
Author: Attila Bukor <[email protected]>
AuthorDate: Wed Jul 22 14:27:55 2020 +0200
[docs] Remove Sentry from documentation
Apache Sentry integration was recently removed. This patch removes its
documentation and the mentions for it.
Change-Id: Ibcbb400453063b1f18163dd87cc27db1679d03d5
Reviewed-on: http://gerrit.cloudera.org:8080/16232
Tested-by: Kudu Jenkins
Reviewed-by: Grant Henke <[email protected]>
---
docs/hive_metastore.adoc | 18 +++---
docs/security.adoc | 156 ++++-------------------------------------------
2 files changed, 22 insertions(+), 152 deletions(-)
diff --git a/docs/hive_metastore.adoc b/docs/hive_metastore.adoc
index ed49ea4..9ec8fe1 100644
--- a/docs/hive_metastore.adoc
+++ b/docs/hive_metastore.adoc
@@ -121,11 +121,11 @@ WARNING: Before enabling the Hive Metastore integration
on an existing cluster,
make sure to upgrade any tables that may exist in Kudu's or in the HMS's
catalog. See <<upgrading-tables>> for more details.
-* When the Hive Metastore is configured with fine-grained authorization
-using Apache Sentry and the Sentry HDFS Sync feature is enabled, the Kudu admin
-needs to be able to access and modify directories that are created for Kudu by
-the HMS. This can be done by adding the Kudu admin user to the group of the
-Hive service users, e.g. by running `usermod -aG hive kudu` on the HMS nodes.
+* When the Hive Metastore is configured with fine-grained authorization, the
+Kudu admin needs to be able to access and modify directories that are created
+for Kudu by the HMS. This can be done by adding the Kudu admin user to the
group
+of the Hive service users, e.g. by running `usermod -aG hive kudu` on the HMS
+nodes.
* Configure the Hive Metastore to include the notification event listener and
the Kudu HMS plugin, to allow altering and dropping columns, and to add full
@@ -195,10 +195,10 @@ able to run the `kudu hms` tools. This can be done by
configuring the user as a
trusted user via the `--trusted_user_acl` master configuration. See
<<security.adoc#trusted-users,here>> for more information about trusted users.
-NOTE: If the Hive Metastore is configured with fine-grained authorization using
-Apache Sentry, the Kudu admin user needs to have read and write privileges on
-HMS table entries. Configured this in the Hive Metastore using the
-`sentry.metastore.service.users` property.
+NOTE: If the Hive Metastore is configured with fine-grained authorization, the
+Kudu admin user needs to have read and write privileges on HMS table entries.
+Configured this in the Hive Metastore. For Apache Sentry this can be configured
+using the `sentry.metastore.service.users` property.
### `kudu hms list`
diff --git a/docs/security.adoc b/docs/security.adoc
index 53c58d7..b1346f3 100644
--- a/docs/security.adoc
+++ b/docs/security.adoc
@@ -154,16 +154,10 @@ to access the cluster.
[[fine_grained_authz]]
== Fine-Grained Authorization
-As of Kudu 1.10.0, Kudu can be configured to enforce fine-grained authorization
+As of Kudu 1.12.0, Kudu can be configured to enforce fine-grained authorization
across servers. This ensures that users can see only the data they are
-explicitly authorized to see. Kudu supports this by leveraging policies
-defined in Apache Sentry 2.2 and later. In addition, starting from Kudu
-1.12.0, Kudu can support fine-grained authorization by leveraging policies
-defined in Apache Ranger 2.1 and later.
-
-WARNING: Since support for Apache Sentry authorization has been deprecated
since
-Kudu 1.12.0 and may be completely removed, fine-grained authorization via
Apache
-Ranger is preferred going forward.
+explicitly authorized to see. Kudu supports this by leveraging policies defined
+in Apache Ranger 2.1 and later.
WARNING: Fine-grained authorization policies are not enforced when accessing
the web UI. User data may appear on various pages of the web UI (e.g. in logs,
@@ -219,8 +213,8 @@ it does not imply that user has `SELECT` privileges on
every table belonging to
that database. On the other hand, Ranger supports privilege wildcard matching.
For example, `db=a->table=\*` matches all the tables that belong to database
`a`.
Therefore, in Ranger users actually need the `SELECT` privilege on
-`db=a->table=*->column=*` to match the semantics of the `SELECT` privilege on
-`db=a` in Sentry.
+`db=a->table=*->column=*` to allow `SELECT` on every table and every column in
+database `a`.
Nevertheless, with Ranger integration, when a Kudu master receives a request,
it consults Ranger to determine what privileges a user has. And the required
@@ -231,67 +225,14 @@ action or not.
NOTE: Even though Kudu table names remain case sensitive with Ranger
integration,
policies authorization is considered case-insensitive.
-=== Apache Sentry
-
-Apache Sentry models tabular objects in the following hierarchy:
-
-* *Server* - indicated by the Kudu configuration flag `--server_name`.
-Everything stored in a Kudu cluster falls within the given "server".
-
-* *Database* - indicated as a prefix of table names with the format
-`<database>.<table>`.
-
-* *Table* - a single Kudu table.
-
-* *Column* - a column within a Kudu table.
-
-Each level of this hierarchy defines a "scope" on which privileges can be
-granted. Privileges granted on a higher scope imply privileges on a lower
-scope. For example, if a user has `SELECT` privilege on a database, that user
-implicitly has `SELECT` privileges on every table belonging to that database.
-
-Privileges are also associated with specific actions. Access to Kudu tables may
-rely on privileges on the following actions:
-
-* `ALTER`
-* `CREATE`
-* `DELETE`
-* `DROP`
-* `INSERT`
-* `UPDATE`
-* `SELECT`
-
-Additionally, there are three special actions recognized by Kudu: `ALL`,
-`OWNER`, and `METADATA`. If a user has the `ALL` or `OWNER` privileges on a
-given table, that user has all of the above privileges on the table.
-`METADATA` privilege is not an actual privilege per se, rather, it is a
-conceptual privilege with which Kudu models any privilege. If a user has any
-privilege on a given table, that user has `METADATA` privileges on the table,
-i.e. a privilege granted on any action on a table implies that the user has
-the `METADATA` privilege on that table.
-
-For more details about Sentry privileges, see the Apache Sentry
-link:https://cwiki.apache.org/confluence/display/SENTRY/Sentry+Privileges[documentation].
-
-NOTE: Depending on the value of the `sentry.db.explicit.grants.permitted`
-configuration in Sentry, certain privileges may not be grantable in Sentry. For
-example, in Sentry deployments that don't support `UPDATE` privileges, to
-perform an operation that requires `UPDATE` privileges, a user must instead
-have `ALL` privileges.
-
-When a Kudu master receives a request, it consults Sentry to determine what
-privileges a user has. If the user is not authorized to perform the requested
-action, the request is rejected. Kudu leverages the authenticated identity of a
-user to decide whether to perform or reject a request.
-
=== Authorization Tokens
Rather than having every tablet server communicate directly with the underlying
-authorization service (e.g. Sentry or Ranger), privileges are propagated and
checked
-via *authorization tokens*. These tokens encapsulate what privileges a user has
-on a given table. Tokens are generated by the master and returned to Kudu
clients
-upon opening a Kudu table. Kudu clients automatically attach authorization
tokens
-when sending requests to tablet servers.
+authorization service (Ranger), privileges are propagated and checked via
+*authorization tokens*. These tokens encapsulate what privileges a user has on
a
+given table. Tokens are generated by the master and returned to Kudu clients
+upon opening a Kudu table. Kudu clients automatically attach authorization
+tokens when sending requests to tablet servers.
NOTE: Authorization tokens are a means to limiting the number of nodes directly
accessing the authorization service to retrieve privileges. As such, since the
@@ -332,14 +273,12 @@ Impala's
link:https://impala.apache.org/docs/build/html/topics/impala_authorization.html#authorization[authorization
documentation].
+[[ranger-configuration]]
=== Configuring the Integration with Apache Ranger
NOTE: Ranger is often configured with Kerberos authentication. See
<<configuration>> for how to configure Kudu to authenticate via Kerberos.
-NOTE: Sentry integration can not be enabled at the same time with Ranger
-integration.
-
* After building Kudu from source, find the `kudu-subprocess.jar` under the
build
directory (e.g. `build/release/bin`). Note its path, as it is the one to the
JAR file containing the Ranger subprocess, which houses the Ranger client that
@@ -454,75 +393,7 @@ Admin web UI:
</property>
```
-[[sentry-configuration]]
-=== Configuring the Integration with Apache Sentry
-
-NOTE: Sentry is often configured with Kerberos authentication. See
-<<configuration>> for how to configure Kudu to authenticate via Kerberos.
-
-NOTE: In order to enable integration with Sentry, a cluster must first be
-integrated with the Apache Hive Metastore. See the
-<<hive_metastore.adoc#enabling-the-hive-metastore-integration,documentation>>
-for how to configure Kudu to synchronize its internal catalog with the Hive
-Metastore.
-
-The following configurations must be set on the master:
-
-```
---sentry_service_rpc_addresses=<Sentry RPC address>
---server_name=<value of HiveServer2's hive.sentry.server configuration>
---kudu_service_name=kudu
---sentry_service_kerberos_principal=sentry
---sentry_service_security_mode=kerberos
-
-# This example ACL setup allows the 'impala' user to access all data stored in
-# Kudu, assuming Impala will authorize requests on its own. The 'hadoopadmin'
-# user is also granted access to all Kudu data, which may facilitate testing
-# and debugging.
---trusted_user_acl=impala,hadoopadmin
-```
-
-The following configurations must be set on the tablet servers:
-
-```
---tserver_enforce_access_control=true
-```
-
-The following configurations must be set in `sentry-site.xml` on the Sentry
servers:
-```xml
-# This example setup configures the Kudu service user as a privileged user to
be
-# able to retrieve authorization policies stored in Sentry.
-<property>
- <name>sentry.service.allow.connect</name>
- <value>kudu</value>
-</property>
-
-<property>
- <name>sentry.service.admin.group</name>
- <value>kudu</value>
-</property>
-```
-
[[privilege-caching]]
-=== Kudu Master Caching for Sentry
-
-To avoid overwhelming Sentry with requests to fetch user privileges, the Kudu
-master can be configured to cache user privileges. A by-product of this caching
-is that when privileges are changed in Sentry, they may not be reflected in
-Kudu for a configurable amount of time, defined by the following Kudu master
-configurations:
-
-`--sentry_privileges_cache_ttl_factor * --authz_token_validity_interval_secs`
-
-The default value is fifty minutes. If privilege updates need to be reflected
-in Kudu sooner than this, the Kudu CLI tool can be used to invalidate the
-cached privileges to force Kudu to fetch new ones from Sentry:
-
-[source,bash]
-----
-kudu master authz_cache reset <master-addresses>
-----
-
=== Ranger Client Caching
On the other hand, privilege cache in Kudu master is disabled with Ranger
integration,
since Ranger provides client side cache the use privileges and can
periodically poll
@@ -543,7 +414,6 @@ The following authorization policy is enforced by Kudu
masters.
|===
| Operation | Required Privilege
| `CreateTable` | `CREATE ON DATABASE`
-| `CreateTable` with a different owner specified than the requesting user |
`ALL ON DATABASE` with the Sentry `GRANT OPTION` (see
link:https://cwiki.apache.org/confluence/display/SENTRY/Support+Delegated+GRANT+and+REVOKE+in+Hive+and+Impala[here])
| `DeleteTable` | `DROP ON TABLE`
| `AlterTable` (with no rename) | `ALTER ON TABLE`
| `AlterTable` (with rename) | `ALL ON TABLE <old-table>` and `CREATE ON
DATABASE <new-database>`
@@ -665,8 +535,8 @@ tablet server) in order to ensure that a Kudu cluster is
secure:
--superuser_acl=hadoopadmin
```
-See <<sentry-configuration>> to see an example of how to enable fine-grained
-authorization via Apache Sentry.
+See <<ranger-configuration>> to see an example of how to enable fine-grained
+authorization via Apache Ranger.
Further information about these flags can be found in the configuration
flag reference.
