Configuring Cloudera Manager Clusters for TLS/SSL

As discussed in Data in Transit Encryption, TLS/SSL is a security protocol designed to prevent eavesdropping, tampering, and message forgery by encrypting network communications. It also supports authentication of host certificates prior to encryption, to prevent spoofing.

Cloudera Levels for TLS/SSL Support

Three increasingly secure TLS levels defined by Cloudera are shown in the table below. These levels have been defined by Cloudera to simply break up TLS/SSL configuration tasks into manageable tasks. Each level provides incrementally stricter security for the cluster.

Level Description and configuration process
Level 1 (Minimal) Encrypted communications between a Web browser and Cloudera Manager, and between Agents and Cloudera Manager. This level encrypts connections between a Web browser running the Cloudera Manager Admin Console and the Cloudera Manager Server.
Level 2 (Better) Encrypted communications (as with Level 1) plus Agents verify authenticity of Cloudera Manager Server's TLS certificate.
Level 3 (Best) Encrypted communications (as with Level 1) and Cloudera Manager Server certificate presentation (as with Level 2), plus each Agent presents a certificate to Cloudera Manager Server to prevent spoofing by untrusted Agents running on hosts. For a start-to-finish configuration guide for Level 3 TLS, see How to Configure TLS Encryption for Cloudera Manager.

As shown in the table, TLS levels are cumulative—Level 1 must be configured before Level 2, and Level 2 must be configured Level 3.

TLS/SSL Configuration and Kerberos Integration

Cloudera recommends that clusters deployed to production be configured using both TLS/SSL for wire (data in transit) encryption and using Kerberos for authentication. Because Cloudera Manager distributes keytabs to the cluster nodes during the process of integrating the cluster with the Kerberos instance (specifically, with the KDC or "Key Distribution Center"), Cloudera recommends that you configure TLS Level 1 for the cluster before integrating Kerberos. This approach ensures that if any keytabs are intercepted, they will not be readable. The recommended sequence is as follows:
  1. Configure TLS/SSL for encryption (through Level 1):
  2. Integrate the cluster with your organization's Kerberos deployment:
  3. Continue configuring TLS/SSL for certificate authentication (Level 2, Level 3):

Plan ahead for the Kerberos integration as part of the TLS/SSL configuration if that is your goal for the cluster. To integrate the cluster with your Kerberos or Active Directory, you must have admin privileges on those systems or help from your organization's Kerberos or Active Directory administrator for that part of the process.

Consider setting up a complete Cloudera Manager cluster without TLS/SSL, unless you have experience with both clusters and TLS/SSL.


In addition to configuration sequence outlined in TLS/SSL Configuration and Kerberos Integration, Cloudera recommends the following:
  • Configure production clusters for TLS Level 3. This is the most secure form of TLS because it authenticates not only the Cloudera Manager Server host but also Cloudera Manager Agent host system certificates before encrypting the communications.
  • Enable TLS/SSL for all services running on the cluster whenever you enable TLS/SSL for any one service. This is especially important for services that work together to process data. For example, if the cluster supports HDFS, MapReduce, and YARN and TLS/SSL has been enabled for the HDFS service, TLS/SSL must be enabled for MapReduce and YARN as well.
  • Configure all clusters managed by any given Cloudera Manager instance for the same TLS level. Cloudera recommends that all clusters managed by a single Cloudera Manager instance have comparable security requirements. Do not manage production clusters, test clusters, and development clusters—all of which likely have different security requirements—from the same Cloudera Manager instance.