Hive Native Authentication

Hive Native authenticates with Kerberos, and the Type selector in the connection form offers nothing else.

That is deliberate. The metastore protocol has no username and password authentication of its own, so a "basic" option would have collected no credential at all: it would have meant "connect to an unauthenticated metastore" while reading as though authentication had taken place. If you need to connect to Hive as a specific named user, use the Hive connector, which goes through HiveServer2 and does support user and password.

Two identities, not one

The most common source of confusion on this connector is that two Kerberos identities are involved, and they are entered in different places.

The Service Principal identifies the metastore you are connecting to. You enter it on the connection, for example hive/_HOST@EXAMPLE.COM. Qualytics uses it to ask for a ticket for the right service. The _HOST portion is replaced with the metastore's own hostname, so a single value works across a highly available metastore. This is not your account, and it is not the identity Qualytics presents.

The Keytab carries the identity Qualytics presents. The keytab you upload on the connection holds the key for the account Qualytics authenticates as, and that account is the one the cluster checks when Qualytics reads a table's files. See Hive Native Permissions for what it needs to be able to read.

Qualytics works out the storage service's principal from the realm of the Service Principal you entered, so there is no separate field for it.

What each field does

Field	Required	What it is for
Service Principal		The metastore's service principal, for example `hive/_HOST@EXAMPLE.COM`.
Keytab		The keytab file for the identity Qualytics should present. When the connection carries none, Qualytics falls back to the Kerberos credentials configured on the deployment.
krb5.conf		The Kerberos configuration for the cluster's realm, so Qualytics knows how to reach that realm's Key Distribution Center. When the connection carries none, the deployment's configuration is used.

Name the keytab file .keytab

Qualytics reads the uploaded file according to its extension, and a keytab is binary. A keytab saved under any other name is read as text and the upload fails. Rename it to end in .keytab before uploading.

Credentials live on the connection

Each connection carries its own Service Principal and its own keytab. Two consequences are worth knowing:

A Kerberized cluster no longer needs deployment-wide Kerberos configuration. On a self-hosted deployment, connecting to a secured cluster used to mean configuring Kerberos for the deployment as a whole. Uploading a keytab on the connection is now enough, and changing a credential is a change to the connection rather than a redeployment.
Several secured clusters can be connected to one Qualytics deployment, each with its own identity and its own krb5.conf.

One realm name, one cluster

The one arrangement that cannot work is two clusters that use the same realm name with different Key Distribution Centers. A realm name cannot mean two clusters at once, so a connection naming a realm another datastore has already claimed is refused rather than quietly reading from the wrong place. Give each cluster a distinct realm name, or connect them from separate deployments.

How the credentials are stored

The keytab is a password equivalent, so it is stored encrypted and never displayed back to you. Once saved, the field shows that a file was previously uploaded rather than its contents.

To change the keytab, upload a new one.
To keep the stored keytab while editing anything else on the connection, leave the field empty and save.

The krb5.conf holds realm names and Key Distribution Center hostnames rather than credentials, so it is not treated as a secret.

Edits apply to every datastore on the connection

Credentials belong to the connection, not to a single datastore. Changing them through Manage Connections changes them for every datastore that reuses that connection.