[
https://issues.apache.org/jira/browse/RANGER-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15088783#comment-15088783
]
Madhan Neethiraj commented on RANGER-768:
-----------------------------------------
bq. 2.2.3 Range HDFS Privilege Changes as Result of Hive Metadata Changes
Please consider the following design to enable HDFS authorization based on
permissions set for corresponding Hive database/tables.
1. As you detailed, changes to Hive database/table storage details should be
processed by a hook. This hook should update Ranger with the details of HDFS
storage locations for Hive databases/tables.
2. The difference from the proposed design is that: instead of using a
first-class HDFS policy for Hive a database/table, the hook should associate
the storage locations as "Implied Resources" to the Hive policy for the
database/table. The implied resource structure would be something like:
{code}
class RangerImpliedPolicyResource {
Long policyId;
String resourceService;
Map<String, RangerPolicyResource> resources;
}
{code}
3. When HDFS plugin downloads the policies from Ranger Admin, in addition to
existing first-class HDFS policies for the service, Ranger Admin will also
include policies for the implied resources. Such a policy will:
- have following attributes same as the Hive policy: ID, name, description,
auditEnabled, etc
- have resources copied from the implied resources of the Hive policy
- include policyItems from the Hive policy, after appropriate mapping of Hive
permission to HDFS permissions
4. Audit logs generated for HDFS access will have ID of the Hive policy, which
will help the user easily identify the cause of allowed/denied access.
5. This design will not require keeping the HDFS policy in sync with its
corresponding Hive policy updates, like changes to users/groups/permissions -
as these are copied dynamically when the policies are sent to HDFS plugin.
6. Since Ranger Admin will delete the implied resources when a Hive policy is
deleted, there is no need to deal with deletion of its corresponding HDFS
policy.
[~yzhou2001] Please review and let me know if you have any questions in this
overall design.
> Hive Metastore Plugin
> ---------------------
>
> Key: RANGER-768
> URL: https://issues.apache.org/jira/browse/RANGER-768
> Project: Ranger
> Issue Type: New Feature
> Components: admin, plugins
> Reporter: Yan
> Attachments: Design Proposal for Hive Metastore Plugin of
> Ranger.docx, Design Proposal for Hive Metastore Plugin of Ranger.docx
>
>
> Currently there is no Ranger processing of Hive table meta store events that
> could result in privilege modifications. One example is that when a table is
> renamed by a Hive Server 2 client (the "beeline"), no proper privilege
> adjustments in Ranger are made to allow/deny previously allowed/denied users
> the same privileges as before. In addition, more advanced features, such as
> granting/denying similar accesses to Hive's HDFS data to users that have (or
> do not have) privileges in the Hive, would require that detailed metadata of
> the Hive table, the storage info to be specific, be available to Ranger in
> order to make the corresponding HDFS data accessible to the Hive users
> directly.
> This plugin will depend upon the existing Ranger Hive plugin, so it shares
> the same "service" name as the associated Ranger Hive service deployed, and
> it will be "co-enabled" with the existing Ranger Hive plugin.
> Design doc will come soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
