Authentication
Overview of authentication in CDP Private Cloud.
Typically a cluster will be integrated with an existing corporate directory, simplifying credentials management and align with well established HR procedures for managing and maintaining both user and service accounts. Kerberos is used to authenticate all service accounts within the cluster with credentials generated in the corporate directory (IDM/AD) and distributed by Cloudera Manager. To ensure that these procedures are secured it’s important that all interactions between CM, the Corporate Directory and the cluster hosts are encrypted using TLS security. Signed Certificates are distributed to each cluster host enabling service roles to mutually authenticate. This includes the Cloudera Agent process which will perform an TLS handshake with the Cloudera Manager server in order that configuration changes such as the generation and distribution of Kerberos credentials are undertaken across an encrypted channel. In addition to the CM agent, all the cluster service roles such as Impala Daemons, HDFS worker roles and management roles typically use TLS.
Kerberos
With Kerberos enabled, all cluster roles are able to authenticate each other
providing they have a valid kerberos ticket. The authentication tickets are issued by the KDC,
typically a local Active Directory Domain Controller, FreeIPA, or MIT Kerberos server with a
trust established with the corporate kerberos infrastructure, upon presentation of valid
credentials. Cloudera Manager generates and distributes these credentials to each of the service
roles using an elevated privilege that is securely maintained within its database. Typically the
administration privilege will enable the creation and deletion of kerberos principles within a
specific organisation unit (OU) within the corporate directory (see, Delegating
Administration by Using OU Objects
). Good practice is to first enable TLS security between
the Cloudera Manager and agents in order to ensure the Kerberos keytab files are transported
over an encrypted connection.
Impersonalisation
Within a CDP system there are two methods of impersonation that are supported. The
first is a simple "doAs" system, where certain services are trusted to assert the identity of
connecting users. For example, Oozie, Hue and Hive are trusted within the CDP environment
to act on behalf of the user who connected to them - this is known as impersonation and is
configured by the hadoop.proxyuser.* set of parameters.
This allows, for example, a user to connect to Hue or HiveServer2 (and we trust Hue/HiveServer2 to correctly identify that user) and then for Hue/HiveServer2 to act on that user's behalf.
Note: When configuring third-party integrations or add-ons, it is possible that they
will require hadoop.proxyuser.* configurations, so that they can also
impersonate users that have connected.
The second method is supported by some implementations of Kerberos, is known as
Constrained Delegation. For further details on constrained delegation, see Accessing Secure
Cluster from Web Applications
.
