Setting up Kerberos for the Db2 Big SQL service

Hadoop uses Kerberos as the basis for strong authentication and identity propagation for both users and services. Kerberos is a third-party authentication mechanism, in which users and services rely on a third party - the Kerberos server or the Key Distribution Center (KDC) - to authenticate each to the other. By using Kerberos for authentication, you make use of a central repository for IDs, also known as principals. Db2® Big SQL introduces its own service principal and makes use of keytab files to store credentials for authentication.

Enabling Kerberos for the cluster and its services, including Db2 Big SQL, is necessary for securing the cluster. Enabling Kerberos for Db2 Big SQL clients is separate and can be optionally set up by following the instructions Enabling Kerberos client authentication.

Before you begin

Refer to the Cloudera Data Platform documentation to enable Kerberos security. The default settings should be sufficient but you can review and modify them for your specific requirements.

Note: Before enabling Kerberos, it is recommended that you replace the Java™ Cryptography Extension (JCE) security policy files in the IBM® JDK used by Db2 Big SQL. If you enforce Advanced Encryption Standard 256-bit (AES-256) encryption or implement HDFS Transparent Encryption this step must be carried out to avoid errors. The files to be replaced are located in path ${DB2_HOME}/java/jdk64/jre/lib/security (where the value of ${DB2_HOME} is /home/bigsql/sqllib if the bigsql user's home directory is set to /home/bigsql). On each host in the cluster you need to replace the default JCE files with IBM SDK policy files.

Procedure

You can install Db2 Big SQL on a Kerberized cluster or Kerberize the cluster after installing Big SQL. For either case, you can choose the automated Kerberos setup for Db2 Big SQL using the CDP wizard or you can choose to manage Kerberos principals and keytabs manually.

  1. Manage Kerberos principals and keytabs for Db2 Big SQL using the CDP wizard

    During the Db2 Big SQL installation process, when the cluster is Kerberized after Db2 Big SQL has been added as a service, the default principal and keytab location for the bigsql service user is shown together with the principals and keytabs of other services.

    Based on the service definition for Db2 Big SQL, CDP will create principals and keytabs for the Db2 Big SQL service user (bigsql) and distribute the keytabs on the cluster nodes where Db2 Big SQL components are placed (under /home/bigsql/.keytabs if the bigsql user's home directory is /home/bigsql).

  2. Manage Kerberos principals and keytabs manually
    If you choose to manage the Db2 Big SQL principals and keytabs manually, before attempting to enable Kerberos in the CDP wizard, make sure to:
    1. Define the principals in the KDC.
    2. Create the keytabs for the principals and distribute to all of the Db2 Big SQL cluster nodes or wherever Db2 Big SQL components are hosted.

The following details apply as a guideline for the principals defined and keytab files generated by the CDP wizard. The same names and conventions can be used when these are managed manually.

The principal names are:
  • bigsql/-CLUSTERNAME@REALM for the headless principal
  • bigsql/_HOST@REALM for the service principal (for each of the component hosts)
where:
  • CLUSTERNAME is replaced by the chosen name of the HDP cluster
  • _HOST is replaced by the cluster host FQDN where Db2 Big SQL components are installed
  • REALM is replaced by the Kerberos realm used for the cluster
The associated keytab files are:
  • bigsql.service.keytab
  • bigsql.headless.keytab
The bigsql.headless.keytab must be distributed to every cluster host where you will be placing a Db2 Big SQL component. Host-specific bigsql.service.keytab files must be copied to the respective host. Also, the permissions for each keytab file must be set to 400 (-r--------) and the file ownership must be bigsql:hadoop.

During CDP wizard-driven Kerberization, a cluster name is used when generating the principal names for service users that are introduced for the stack services. This helps prevent a clash of principal names at a KDC server shared with other clusters. When managing Kerberos principals and keytabs manually, remember to add a unique identifiable string, such as the cluster name, to each of the headless keytabs.