Hive Native Permissions

Two separate things have to be granted before someone can put a Hive Native datastore to work, and they are granted in different places:

• On your Hive cluster, the identity Qualytics connects with needs read access to the metastore and to the table files. Without it the connection cannot read your data at all.
• In Qualytics, the person doing the work needs a user role and a team permission. Without them the datastore exists but they cannot create, change, or run operations on it.

The rest of this page covers both, in that order.

Access on your Hive Cluster

Because Hive Native reads the data files themselves, it needs more than a working metastore connection. Reaching the metastore alone is enough to list databases and tables, and a datastore set up that way syncs successfully and then fails the first time it tries to profile or scan. Grant the access below before the first operation, not after.

Qualytics never writes to Hive through this connector, so read access is all it asks for.

What the connection needs

On HDFS, file access is checked against the identity Qualytics presents. An identity that can list tables but cannot read the warehouse directory produces exactly the failure described above: a clean sync, then an error on the first profile.

Network access

Allow your Qualytics deployment to reach the services below. The Add Datastore form shows the addresses your connections originate from, under Public addresses and Private addresses, so you can copy the ones that match your network setup into your security groups or firewall rules.

The DataNode port differs by cluster. Secured clusters commonly use the privileged port 1004, while unsecured clusters commonly use 9866. Check dfs.datanode.address on your cluster if you are unsure.

Hostname resolution

Table and partition locations recorded in the metastore usually name hosts rather than IP addresses, for example hdfs://hive-primary.internal:8020/warehouse/sales. Qualytics follows those locations exactly as the metastore reports them, so every hostname they contain has to resolve from your Qualytics deployment. If a name resolves only inside the cluster, add the records to the DNS your deployment uses.

This is the most common reason a connection that tested successfully cannot read data: the metastore was reachable by its own address, and the storage hosts it named were not.

Kerberos permissions

The identity Qualytics presents through its keytab needs the same two kinds of access listed above: read on the Hive databases and tables you want to monitor, and read on their files in storage. Granting it on the metastore alone is not sufficient.

See Hive Native Authentication for which identity is which, and where each one is entered on the connection.

Permissions in Qualytics

Qualytics checks two layers, and an action is allowed only when both pass.

• User roles are workspace-wide: Member, Manager, and Admin.
• Team permissions are granted per datastore through the teams a user belongs to: Reporter, Viewer, Drafter, Author, and Editor.

For the full reference, see User Roles and the Team Permissions Overview.

User Roles

Team Permissions

Checked on the datastore itself, in addition to the user role above.

How the two layers meet

To create a Hive Native datastore, a user needs the Manager role. Team permissions are not consulted, because the datastore does not exist yet.

To edit it, run an operation on it, or link an enrichment destination, a user needs the Member role or higher and the Editor team permission on that datastore, through at least one of the teams the datastore belongs to.

To delete it, or to unlink its enrichment destination, a user needs the Admin role. No team permission is consulted.

See Also