Create the Vertica principals and keytabs on Linux KDC

Vertica uses service principals for system-level operations. These principals identify the Vertica service and are used as follows:

• Kerberized Vertica clients request access to this service when they authenticate to the database.

• System processes like the Tuple Mover use this identity when they authenticate to external services such as Hadoop.

Create principals and keys as follows:

1. Start the Kerberos 5 database administration utility (kadmin or kadmin.local) to create Vertica principals on a Linux KDC.

   • Use kadmin if you are accessing the KDC on a remote server. If you have access to the Kerberos administrator password, you can use kadmin on any machine where the Kerberos 5 client package is installed. When you start kadmin, the utility prompts you for the Kerberos administrator's password. You might need root privileges on the client to run kadmin.

   • Use kadmin.local if:

     • The KDC is on the machine that you are logging in to.

     • You have root privileges on that server.

   kadmin.local does not require the administrators login credentials.

   For more information about the kadmin and kadmin.local commands, see the kadmin documentation.

2. Create one service principal for Vertica on each node. The host name must match the value supplied by the operating system. The following example creates the service principal vertica for the node named v_vmart_node0001.example.com:

   $ sudo /usr/kerberos/sbin/kadmin.local
   kadmin.local add_principal vertica/v_vmart_node0001.example.com
   

   Repeat the ktadd command once per principal. You can create separate keytabs for each principal user or add them all to a single keytab file (such as krb5.keytab). If you are using a single file, see the documentation for the -glob option in the MIT Kerberos documentation.

   You must have a user principal for each Vertica Analytic Database user that uses Kerberos Authentication. For example:

   $ sudo /usr/kerberos/sbin/kadmin.local
   kadmin.local add_principal [options] VerticaUser1
   

3. Copy each keytab file to the /etc folder on the corresponding cluster node. Use the same path and file name on all nodes.

4. On each node, make the keytab file readable by the file owner who is running the database process (typically, the Linux dbadmin user). For example, you can change ownership of the files to dbadmin as follows:

   $ sudo chown dbadmin *.keytab
   

   Important

   In a production environment, you must control who can access the keytab file to prevent unauthorized users from delegating your server. For more information about delegation (also known as impersonation), see Technet.Microsoft.com.

   After you create a keytab file, you can use the klist command to view keys stored in the file:

   $ sudo /usr/kerberos/bin/klist -ke -t
   Keytab name: FILE:/etc/krb5.keytab
   KVNO    Timestamp        Principal
   ---- ------------------- --------------------------------------------------------------------------
   4     08/15/2017 7:35:41 vertica/v_vmart_node0001.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   4     08/15/2017 7:35:41 vertica/v_vmart_node0001.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
   

5. On Vertica run the following to ensure the Kerberos parameters are set correctly:

   => select parameter_name, current_value from configuration_parameters where parameter_name like 'Ker%';
   parameter_name         |                      current_value
   -----------------------+---------------------------------------------------------------------
   KerberosHostname       | v_vmart_node0001.example.com
   KerberosKeytabFile     | /etc/krb5.keytab
   KerberosRealm          | EXAMPLE.COM
   KerberosTicketDuration | 0
   KerberosServiceName    | vertica
   (5 rows)
   

6. Ensure that all clients use the gss authentication method.

   From Vertica:

   => CREATE USER bob;
   CREATE USER
   
   => CREATE AUTHENTICATION v_kerberos method 'gss' host '0.0.0.0/0';
   CREATE AUTHENTICATION
   
   => ALTER AUTHENTICATION v_kerberos enable;
   ALTER AUTHENTICATION
   
   => GRANT AUTHENTICATION v_kerberos to bob;
   GRANT AUTHENTICATION
   

   From the operating system command line:

   $ kinit bob
   
   $ vsql -U bob -k vertica -K v_vmart_node0001.example.com -h v_vmart_node0001 -c "select client_authentication_name,
   authentication_method from sessions;"
    client_authentication_name | authentication_method--
   ----------------------------+-----------------------
    v_kerberos                 |    GSS-Kerberos
   
   (1 row)
   

7. On Vertica, run KERBEROS_CONFIG_CHECK to verify the Kerberos configuration. KERBEROS_CONFIG_CHECK verifies the following:

   • The existence of the kinit and kb5.conf files.

   • Whether the keytab file exists and is set

   • The Kerberos configuration parameters set in the database:

     • KerberosServiceName

     • KerberosHostname

     • KerberosRealm

     • Vertica Principal

   • That Kerberos can read the Vertica keys

   • That Kerberos can get the tickets for the Vertica principal

   • That Vertica can initialize the keys with kinit