Enabling Kerberos Authentication Using the Wizard

Minimum Required Role: Cluster Administrator (also provided by Full Administrator)

This guide describes how to use Cloudera Manager and the Kerberos wizard (introduced in Cloudera Manager 5.1.0) to automate many of the manual tasks of implementing Kerberos security on your CDH cluster.
  • Prerequisites - These instructions assume you know how to install and configure Kerberos, you already have a working Kerberos key distribution center (KDC) and realm setup, and that you've installed the following Kerberos client packages on all cluster hosts and hosts that will be used to access the cluster, depending on the OS in use.
    OS Packages to be Installed
    RHEL/CentOS 5, RHEL/CentOS 6
    • openldap-clients on the Cloudera Manager Server host
    • krb5-workstation, krb5-libs on ALL hosts
    SLES
    • openldap2-client on the Cloudera Manager Server host
    • krb5-client on ALL hosts
    Ubuntu or Debian
    • ldap-utils on the Cloudera Manager Server host
    • krb5-user on ALL hosts
    Windows
    • krb5-workstation, krb5-libs on ALL hosts
    Furthermore, Oozie and Hue require that the realm support renewable tickets. Cloudera Manager supports setting up kerberized clusters with MIT KDC and Active Directory.

    For more information about using Active Directory, refer the section below on Considerations when using an Active Directory KDC and the Microsoft AD documentation.

    For more information about installing and configuring MIT KDC, see:
  • Support
    • Kerberos security in Cloudera Manager has been tested on the following version of MIT Kerberos 5:
      • krb5-1.6.1 on Red Hat Enterprise Linux 5 and CentOS 5
    • Kerberos security in Cloudera Manager is supported on the following versions of MIT Kerberos 5:
      • krb5-1.6.3 on SLES 11 Service Pack 1
      • krb5-1.8.1 on Ubuntu
      • krb5-1.8.2 on Red Hat Enterprise Linux 6 and CentOS 6
      • krb5-1.9 on Red Hat Enterprise Linux 6.1
      In addition, Cloudera supports the version of Kerberos that ships with each supported operating system.

Considerations when using an Active Directory KDC

Performance:

As your cluster grows, so will the volume of Authentication Service (AS) and Ticket Granting Service (TGS) interaction between the services on each cluster server. Consider evaluating the volume of this interaction against the Active Directory domain controllers you have configured for the cluster before rolling this feature out to a production environment. If cluster performance suffers, over time it might become necessary to dedicate a set of AD domain controllers to larger deployments.

Network Proximity:

By default, Kerberos uses UDP for client/server communication. Often, AD services are in a different network than project application services such as Hadoop. If the domain controllers supporting a cluster for Kerberos are not in the same subnet, or they're separated by a firewall, consider using the udp_preference_limit = 1 setting in the [libdefaults] section of the krb5.conf used by cluster services. Cloudera strongly recommends against using AD domain controller (KDC) servers that are separated from the cluster by a WAN connection, as latency in this service will significantly impact cluster performance.

Process:

Troubleshooting the cluster's operations, especially for Kerberos-enabled services, will need to include AD administration resources. Evaluate your organizational processes for engaging the AD administration team, and how to escalate in case a cluster outage occurs due to issues with Kerberos authentication against AD services. In some situations it might be necessary to enable Kerberos event logging to address desktop and KDC issues within windows environments.

Also note that if you decommission any Cloudera Manager roles or nodes, the related AD accounts will need to be deleted manually. This is required because Cloudera Manager will not delete existing entries in Active Directory.