Automatic TLS Configuration with Cloudera Director 2.6

Categories: Cloudera Director Cloudera Manager Platform Security & Cybersecurity

Cloudera Director 2.6 and Cloudera Manager 5.13 offer a simple way to have TLS configured for Cloudera Manager and CDH clusters. In this blog post, Bill Havanki describes how to use the new feature and offers technical details behind how the automatic configuration happens.

Why TLS in the Cloud

An important tenet of information security is defense in depth. The idea behind defense in depth is to have multiple layers of security protecting valued assets, so that if one layer should fail, the others remain working. A real life example of defense in depth is a European castle; an outer perimeter of walls provides one layer of defense, while a fortified keep inside the walls provides another. If a wall fails, for example, then the keep still holds.

A virtual network in a cloud provider like Microsoft Azure, AWS, or Google Cloud Platform is automatically provided with security measures like firewall rules that prevent entities from outside the network from accessing it. However, if an attacker is able to penetrate the network, perhaps through erroneous security configuration, then you may have greater peace of mind knowing other security measures are in place internally, providing deeper defenses.

Using TLS (transport layer security) is one popular security measure for networks. It enables encryption of network traffic such that intruders cannot observe its contents. It also uses certificates to let entities in the network verify that they are indeed communicating with intended parties.

TLS is supported across the Cloudera platform, and that includes Cloudera Director and Cloudera Manager. When those products have TLS enabled, access to their web interfaces is restricted to secure HTTP (https). Cloudera Manager’s various daemons and agents also communicate among themselves using TLS. Moreover, many services in CDH clusters support TLS communication, so that cluster traffic is protected from third party observation. With TLS in place for all of these communication channels, your CDH clusters are much more secure.

Cloudera Director 2.6 and Cloudera Manager 5.13 provide a new capability to automatically configure TLS for Cloudera Manager and CDH clusters. The new capability is called automatic TLS. When you use automatic TLS, communication between Cloudera Director and Cloudera Manager is protected by TLS, as is communication among Cloudera Manager daemons and agents, and within CDH clusters, all with very little work on your part.

How to Use Automatic TLS

You must use Cloudera Director 2.6 or higher and Cloudera Manager 5.13 or higher to take advantage of automatic TLS. Automatic TLS cannot be applied to existing Cloudera Manager installations or CDH clusters.

Automatic TLS is triggered by setting a configuration property in a Cloudera Director configuration file. The flag is called “tlsEnabled”, and it lives in the “cloudera-manager” section of the configuration file. Here is an example snippet.

Including this flag in a configuration file is all you need to do to activate automatic TLS. When you use a configuration file with the “tlsEnabled” flag set in order to bootstrap a Cloudera Manager installation and a CDH cluster, TLS communications are automatically established for you.

How Automatic TLS Works

When you request automatic TLS for a Cloudera Manager installation, Cloudera Director performs some work on your behalf to inform Cloudera Manager of your request. The most important component of that work is the establishment of a local certificate authority (CA) on the Cloudera Manager instance. All of the files and tooling for the CA are resident on the Cloudera Manager instance. Key pairs are generated on the instance, and certificates for the public keys are signed by the CA using its root certificate. This CA can be called a bespoke CA, because it is custom made for the Cloudera Manager installation. Two Cloudera Manager installations have independent bespoke CAs.

As part of automatic TLS configuration, Cloudera Manager configures itself completely for TLS communication, all the way up to Level 3. This means that all communication among Cloudera Manager components is protected by TLS, and Cloudera Director must itself use TLS to talk to Cloudera Manager.

Cloudera Director exports the server certificate used by Cloudera Manager for its API and remembers it, using it as the contents of the trusted certificate store for TLS communications with Cloudera Manager. Cloudera Director remembers the certificate for each Cloudera Manager installation separately, so that it can work with multiple installations.

Besides configuring itself for TLS automatically, Cloudera Manager updates the configuration of CDH cluster services so that they also require TLS for communication. This protects cluster traffic with encryption and certificate checks, not just within the cluster, but also for common user endpoints like web interfaces.

Which CDH Services are Covered

The following CDH services are handled by automatic TLS with Cloudera Director 2.6 and Cloudera Manager 5.13. As time goes on, more services will be supported.

  • HDFS: clients, namenode web UI
  • Hive: Hive Server 2
  • Hue: client, load balancer, server
  • Impala: catalog server, server, statestore server
  • Navigator
  • Oozie
  • Spark on YARN: history server
  • YARN: web UI
  • HttpFS

Limitations and Caveats

Automatic TLS creates bespoke CAs, each of which has a self-signed root certificate that is not trusted automatically by web browsers or other clients. You should expect that those applications will warn about the untrusted nature of the certificates used for Cloudera Manager and CDH cluster endpoints. While the warnings can be dismissed or ignored, you may instead import the CA root certificate into the clients’ trusted certificate stores.

Heavy use of automatic TLS leads to an abundance of untrusted root certificates. Instead of constantly updating clients with new certificates to trust, access to the Cloudera Manager and CDH cluster instances can be managed by a reverse proxy. The proxy can accept and terminate TLS sessions with a common, trusted server certificate, and forward requests onward to the desired endpoints, also over TLS. Other features of a proxy can play a role in your defense-in-depth strategy.

There is no mechanism for having the root certificate for a bespoke CA be, itself, signed by  another trusted CA, such as one already established for your organization. However, in case you’d like to use your own signing certificate, perhaps as part of a corporate CA, Cloudera Director does have a workflow for establishing trust in a Cloudera Manager installation where TLS was configured manually, in accordance with Cloudera Manager documentation on the subject.

Automatic TLS does not cover all CDH cluster services. The list of supported services is provided above.

For More Information

Automatic TLS support is covered in Cloudera Director’s TLS documentation. The documentation also describes how to perform manual TLS configuration and how to configure TLS for Cloudera Director itself.

If you’d like to try automatic TLS or any of the other new support for TLS, download and install the latest Cloudera Director release.



One response on “Automatic TLS Configuration with Cloudera Director 2.6

  1. Michael Arnold

    I would like to see the feature implemented where the bespoke root CA is actually provided by the corporate environment and Auto-TLS generates an intermediate root CA CSR that is then signed by the corporate root. Too many of my clients have security policies that dictate a single, company-controlled root CA and no application-specific bespoke CAs. Auto-TLS becomes a non-starter in these environments.

    When can we expect to see such a feature?