Improvement on hive Permissions

Insufficient

Even if hive permission authentication is enabled, any user is still a Super User and can grant any permissions to anyone through grant. Therefore, permission authentication is meaningless, therefore, when permission authentication is enabled, you must restrict the objects that execute grant/revoke. For example, only the admin can grant privilege on database, and only the table owner can grant privilege on table. Currently, permission authentication is not enabled for hive in Bip.

Improvement

For the lack of hive permissions and the use of BIP for hive, the improved hive permission authentication has a role with super permissions admin_role, that is, admin_role has all the same permissions when permission authentication is not enabled. the user with admin_role is admin, A common user can perform operations on an object only when the owner of an object is granted the corresponding permissions:

1. Database permissions: Only one database in hive_warehouse of BIP, that is, the default dB default. Only the admin can manage the database permissions, mainly including: create/drop database, grant/Revoke privilege on Database

2. Table/column permissions: A common user can create a table only after being granted the create on database operation. After a table is created, admin_role and owner have all permissions, and can grant/Revoke privilege on table only if they have all permissions on the table, other users or their role can be authorized to perform corresponding operations.

3. permissions on Role: Only admin_role has the right to create/drop role. Therefore, only admin can perform permission-related operations on role.

4. Only admin_role has the proxy permission, that is, admin_role can be converted to bip. the user performs all hive operations. At this time, the creation and read/write of the table are based on the bip of the proxy. user identity execution, applicable to bip web scenarios

 

Hive parses hql in four steps: lexical analysis, syntax analysis, semantic analysis, and execution. lexical analysis and syntax analysis mainly form an abstract syntax tree ast to ensure the correctness of hql syntax, semantic Analysis translates ast into tasks and analyzes the relationships between tasks to form a directed acyclic graph Dag, the final execution engine submits tasks in the Dag to hadoop for execution and monitors the execution status of tasks. By performing permission verification in semantic analysis, hive checks whether the user has the corresponding permissions for the table and column that execute hql operations, at the same time, Hook is enabled to allow us to operate on the input and output of semantic analysis. the following attributes can be used to configure the hook class of semantic analysis:

<Property>

<Name> hive. semantic. analyzer. Hook </Name>

<Value> com. Bip. hive. Auth. authhook> </value>

</Property>

The Semantic Analysis hook class must inherit from the abstract class abstractsemanticanalyzerhook to implement preanalyze pre-semantic analysis check and post-semantic analysis. The custom permission check is implemented in preanalyze. In the semantic hook, we obtain the user's identity and determine whether the user can perform certain operations, thus distinguishing the admin and non-Admin execution permissions.

By default, hive uses hadoopdefaultauthenticator to obtain the user who executes hql and uses the user returned for permission verification. To enable hive to run in proxy mode, we need to provide our own authenticator and return the set Bip. user as the real hql executor. You can set authenticator in the following Configuration:

<Property>

<Name> hive. Security. authenticator. Manager </Name>

<Value> com. PPLIVE. Bip. hive. Auth. authenticator </value>

<Description> BIP user authenticator </description>

</Property>

Currently, admin defines the bip. User variable in the hive command line to start hive and enter the proxy mode:

Hive-D bip. User = xxx or hive -- Define Bip. User = xxx

Memo

Hive also provides the Group permission management function. It is not recommended that you manage group-related permissions when role can meet your needs.

The improvement of hive permission management can prevent unauthorized users from reading, writing, and deleting tables and columns without permissions, and audit the executed hql, analyze the execution time and frequency of hql and the use frequency of hive tables.

The permission information related to permission management based on metadata is stored in hive metadata. In fact, permission information can also be stored in our own dB, so that we can grasp the permission control rules by ourselves, you do not need to enable hive permission control. After semanticanalyze, you can control the tables and Fields read and written by hql based on our rules.

However, even the improved hive permissions are still weak, because all the information related to hive permissions is stored in metadata, as long as you know the MySQL user name and password that stores metadata, You can arbitrarily modify the permission metadata, and the information connected to metadata MySQL is configured in plaintext in the hive-site.xml, therefore, the most secure permission is based on the underlying access control of storage.