Cloudera Manager Administration Guide

(1)

(2)

Important Notice

Cloudera, the Cloudera logo, Cloudera Impala, and any other product or service names or slogans contained in this document are trademarks of Cloudera and its suppliers or licensors, and may not be copied, imitated or used, in whole or in part, without the prior written permission of Cloudera or the applicable trademark holder.

Hadoop and the Hadoop elephant logo are trademarks of the Apache Software Foundation. All other trademarks, registered trademarks, product names and company names or logos mentioned in this document are the property of their respective owners. Reference to any products, services, processes or other information, by trade name, trademark, manufacturer, supplier or otherwise does not constitute or imply endorsement, sponsorship or recommendation thereof by us.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Cloudera.

Cloudera may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Cloudera, the furnishing of this document does not give you any license to these patents, trademarks copyrights, or other intellectual property. For information about patents covering Cloudera products, see http://tiny.cloudera.com/patents.

The information in this document is subject to change without notice. Cloudera shall not be liable for any damages resulting from technical errors or omissions which may be present in this document, or from use of this document.

Cloudera, Inc.

(3)

This guide is for system administrators who need to manage a Cloudera Manager server installation. This guide covers managing the Cloudera Manager Server and Agents, managing the Cloudera Management Service, adding and managing Cloudera Manager users, configuring TLS security, upgrading Cloudera Manager, adding or upgrading licenses, configuring the Alert Publisher, and other similar features.

(8)

(9)

Managing the Cloudera Manager Server and Agents

This section covers information on managing the Cloudera Manager Server and Agents that run on each host of the cluster.

Starting, Stopping, and Restarting the Cloudera Manager Server

To start the Cloudera Manager Server:

$ sudo service cloudera-scm-server start

You can stop (for example, to perform maintenance on its host) or restart the Cloudera Manager Server without affecting the other services running on your cluster. Statistics data used by activity monitoring and service monitoring will continue to be collected during the time the server is down.

To stop the Cloudera Manager Server:

$ sudo service cloudera-scm-server stop

To restart the Cloudera Manager Server:

$ sudo service cloudera-scm-server restart

Configuring Cloudera Manager Server Ports

Required Role:

1. Select Administration > Settings.

2. Under the Ports and Addresses category, set the following options as described below: Description

Setting

Specify the HTTP port to use to access the Server via the Admin Console.

HTTP Port for Admin Console

Specify the HTTPS port to use to access the Server via the Admin Console.

HTTPS Port for Admin Console

Specify the port for Agents to use to connect to the Server.

Agent Port to connect to Server

3. Click Save Changes.

4. Restart the Cloudera Manager Server.

Moving the Cloudera Manager Server to a New Host

You can move the Cloudera Manager Server if the database information is still available for either of the following reasons:

• The database server is still available.

• A current back up of the Cloudera Manager database is available. To move Cloudera Manager Server:

(10)

1. Record the old host's name hostname and IP address. It is not absolutely necessary to have the old Cloudera Manager server hostname and IP address, but it simplifies the process. You could use a new hostname and IP address, but this would require updating the configuration of every Agent to use this new information. Because it is easier to use the old server hostname and address in most cases, using a new hostname and IP address is not described.

2. Identify a new host on which to install Cloudera Manager. Assign the failed Cloudera Manager Server's hostname and IP address to the new host.

Note: If the Agents were configured with the server's hostname, you do not need to assign the old host's IP address to the new host. Simply assigning the hostname will suffice.

3. Install Cloudera Manager on a new host, using the method described under Install the Cloudera Manager Server Packages. Do not install the other components, such as CDH and databases.

4. If the database server is not available,

a. Install the database packages on the host that will host the restored database. This could be the same host on which you have just installed Cloudera Manager or it could be a different host. The details of which package to install varies based on which database was initially installed on your system. If you used the embedded PostgreSQL database, install the PostgreSQL package as described in Embedded PostgreSQL Database. If you used an external MySQL, PostgreSQL, or Oracle database, reinstall that following the instructions in Cloudera Manager and Managed Service Databases.

b. Restore the backed up databases to the new database installations.

5. Update /etc/cloudera-scm-server/db.properties with the necessary information so that the Cloudera Manager Server connects to the restored database. This information is typically the database name, database instance name, user name, and password.

6. Start the Cloudera Manager Server.

At this point, Cloudera Manager should resume functioning as it did before the failure. Because you restored the database from the backup, the server should accept the running state of the Agents, meaning it will not terminate any running processes.

The process is similar with secure clusters, though files in /etc/cloudera-scm-server must be restored in

addition to the database.

Starting, Stopping, and Restarting Cloudera Manager Agents

Starting Agents

To start Agents, the supervisord process, and all managed service processes, use one of the following commands:

• Start

$ sudo service cloudera-scm-agent start

• Clean Start

$ sudo service cloudera-scm-agent clean_start

The directory /var/run/cloudera-scm-agent is completely cleaned out; all files and subdirectories are

removed, and then the start command is executed. /var/run/cloudera-scm-agent contains on-disk

running Agent state. Some Agent state is left behind in /var/lib/cloudera-scm-agent, but you shouldn't

delete that. For further information, see Server and Client Configuration and Process Management.

Stopping and Restarting Agents

To stop or restart Agents while leaving the managed processes running, use one of the following commands:

10 | Cloudera Manager Administration Guide

(11)

• Stop

$ sudo service cloudera-scm-agent stop

• Restart

$ sudo service cloudera-scm-agent restart

Hard Stopping and Restarting Agents

Warning: The hard_stop, clean_restart, or hard_restart commands kill all running managed

service processes on the host(s) where the command is run.

To stop or restart Agents, the supervisord process, and all managed service processes, use one of the following

commands: • Hard Stop

$ sudo service cloudera-scm-agent hard_stop

• Hard Restart

$ sudo service cloudera-scm-agent hard_restart

Hard restart is useful for the following situations:

1. You're upgrading Cloudera Manager and the supervisord code has changed between your current version

and the new one. To properly do this upgrade you'll need to restart supervisor too. 2. supervisord is hung and needs to be restarted.

3. You want to clear out all running state pertaining to Cloudera Manager and managed services. • Clean Restart

$ sudo service cloudera-scm-agent clean_restart

Runs hard_stop followed by clean_start.

Checking Agent Status

To check the status of the Agent process, use the command:

$ sudo service cloudera-scm-agent status

Configuring Cloudera Manager Agents

Required Role:

Cloudera Manager Agents can be configured globally using properties you set in the Cloudera Manager Admin Console and by setting properties in individual Agent configuration files.

Configuring Agent Heartbeat and Health Status Options

You can configure the Cloudera Manager Agent heartbeat interval and timeouts to trigger changes in Agent

health as follows:

(12)

2. Under the Performance category, set the following option: Description

Property

The interval in seconds between each heartbeat that is sent from Cloudera Manager Agents to the Cloudera Manager Server. Default: 15 sec.

Send Agent Heartbeat Every

3. Under the Monitoring category, set the following options: Description

Property

The number of missed consecutive heartbeats after which a Concerning health status is assigned to that Agent.

Default: 5. Set health status to Concerning if

the Agent heartbeats fail

The number of missed consecutive heartbeats after which a Bad health status is assigned to that Agent.

Default: 10. Set health status to Bad if the

Agent heartbeats fail

4. Click Save Changes.

Configuring the Host Parcel Directory

To configure the location of distributed parcels: 1. Click Hosts in the top navigation bar. 2. Click the Configuration tab.

3. Configure the value of the Parcel Directory property. The setting of the parcel_dir property in the Cloudera

Manager Agent configuration file overrides this setting. 4. Click Save Changes to commit the changes.

Agent Configuration File

The Cloudera Manager Agent supports different types of configuration options in the

/etc/cloudera-scm-agent/config.ini file. You must update the configuration on each host.

Description Property

Hostname and ports of the Cloudera Manager Server and Agent and IP address of the Agent. Also see Configuring Cloudera Manager Server Ports

on page 9 and Ports Used by Cloudera Manager.

The Cloudera Manager Agent configures its hostname automatically. However, if your cluster hosts are multi-homed (that is, they have more

server_host, server_port, listening_port,

listening_hostname, listening_ip

than one hostname), and you want to specify which hostname the Cloudera Manager Agent uses, you can update the listening_hostname

property. If you want to specify which IP address the Cloudera Manager Agent uses, you can update the listening_ip property in the same file. To have a CNAME used throughout instead of the regular hostname, an Agent can be configured to use listening_hostname=CNAME. In this

case, the CNAME should resolve to the same IP address as the IP address of the hostname on that machine. Users doing this will find that the host inspector will report problems, but the CNAME will be used in all

configurations where that's appropriate. This practice is particularly useful for users who would like clients to use

(13)

namenode.mycluster.company.com instead of machine1234.mycluster.company.com. In this case,

namenode.mycluster would be a CNAME for machine1234.mycluster,

and the generated client configurations (and internal configurations as well) would use the CNAME.

The path to the Agent log file. If the Agent is being started via the init.d

script, /var/log/cloudera-scm-agent/cloudera-scm-agent.out will also have a small amount of output (from before logging is initialized). Default: /var/log/cloudera-scm-agent/cloudera-scm-agent.log. log_file

Directory to store Cloudera Manager Agent state that persists across instances of the agent process and system reboots. The agent's UUID is stored here.

Default: /var/lib/cloudera-scm-agent. lib_dir

Directory to store unpacked parcels. Default: /opt/cloudera/parcels.

parcel_dir

Maximum time to wait for all metric collectors to finish collecting data. Default: 10 sec.

max_collection_wait_seconds

Maximum time to wait when connecting to a local role's web server to fetch metrics.

Default: 30 sec.

metrics_url_timeout_seconds

Maximum time to wait when connecting to a local TaskTracker to fetch task attempt data.

Default: 5 sec.

task_metrics_timeout_seconds

Security-related configuration. See

use_tls,verify_cert_file, client_key_file,

• Configuring TLS Authentication of Agents to Server on page 37

client_keypw_file,

client_cert_file • Configuring TLS Authentication of Server to Agents on page 33

• Specifying the Cloudera Manager Server Certificate

• Adding a Host to the Cluster

Directory to store Cloudera Management Service files. Default: /usr/share/cmf.

mgmt_home

Location of JDBC drivers. See Cloudera Manager and Managed Service Databases. Default: cloudera_mysql_connector_jar, cloudera_oracle_connector_jar, cloudera_postgresql_jdbc_jar • MySQL - /usr/share/java/mysql-connector-java.jar • Oracle - /usr/share/java/oracle-connector-java.jar • PostgreSQL -/usr/share/cmf/lib/postgresql-version-build.jdbc4.jar

(14)

Viewing Cloudera Manager Server and Agent Logs

To help you troubleshoot problems, you can view the Cloudera Manager Server and Agent logs. You can view these logs in the Logs page or in specific pages for the logs.

Viewing Cloudera Manager Server and Agent Logs in the Logs Page

1. Select Diagnostics > Logs on the top navigation bar. 2. Click Select Sources to display the log source list. 3. Uncheck the All Sources checkbox.

4. Check the Cloudera Manager checkbox to view both Agent and Server logs, or click to the left of Cloudera Manager, and check either the Agent or Server checkbox.

5. Click Search.

For more information about the Logs page, see Logs.

Viewing the Cloudera Manager Server Log

1. Select Diagnostics > Server Log on the top navigation bar. Note: You can also view the Cloudera Manager Server log at

/var/log/cloudera-scm-server/cloudera-scm-server.log on the server host.

Viewing the Cloudera Manager Agent Log

1. Click the Hosts tab.

2. Click the link for the host where you want to see the Agent log. 3. In the Details panel, click the Details link in the Host Agent field. 4. Click the Agent Log link.

Note: You can also view the Cloudera Manager Agent log at

/var/log/cloudera-scm-agent/cloudera-scm-agent.log on the Agent hosts.

Changing Hostnames

Required Role:

Important: The process described here requires Cloudera Manager and cluster downtime.

After you have installed Cloudera Manager and created a cluster, you may need to update the names of the hosts running the Cloudera Manager Server or cluster services. To update a deployment with new hostnames, follow these steps:

1. Verify if SSL/TLS certificates have been issued for any of the services and make sure to create new SSL/TLS certificates in advance for services protected by TLS/SSL. Review Cloudera Manager and CDH documentation at Cloudera Documentation.

Tip: Search for SSL and TLS in the documentation.

2. Export the Cloudera Manager configuration using one of the following methods:

• Open a browser and go to this URL http://cm_hostname:7180/api/api_version/cm/deployment.

Save the displayed configuration.

(15)

• From terminal type:

$ curl -u admin:admin http://cm_hostname:7180/api/api_version/cm/deployment > cme-cm-export.json

If Cloudera Manager SSL is in use, specify the -k switch:

$ curl -k -u admin:admin http://cm_hostname:7180/api/api_version/cm/deployment > cme-cm-export.json

where cm_hostname is the name of the Cloudera Manager host and api_version is the correct version of the API for the version of Cloudera Manager you are using. For example,

http://tcdn5-1.ent.cloudera.com:7180/api/v6/cm/deployment. 3. Stop all services on the cluster.

4. Stop the Cloudera Management Service. 5. Stop the Cloudera Manager Server.

6. Stop the Cloudera Manager Agents on the hosts that will be having the hostname changed.

7. Back up the Cloudera Manager Server database using mysqldump, pg_dump, or another preferred backup

utility. Store the backup in a safe location. 8. Update names and principals:

a. Update the target hosts using standard per-OS/name service methods (/etc/hosts, dns, /etc/sysconfig/network, hostname, and so on). Ensure that you remove the old hostname.

b. If you are changing the hostname of the host running Cloudera Manager Server do the following: a. Change the hostname per step 8.a.

b. Update the Cloudera Manager hostname in /etc/cloudera-scm-agent/config.ini on all Agents. c. If the cluster is configured for Kerberos security, do the following:

a. In the Cloudera Manager database, set the merged_keytab value:

• PostgreSQL

update roles set merged_keytab=NULL;

• MySQL

update ROLES set MERGED_KEYTAB=NULL;

b. Remove old hostname cluster service principals from the KDC database using one of the following: • Use the delprinc command within kadmin.local interactive shell.

• From the command line:

kadmin.local -q "listprincs" | grep -E

Open cluster-princ.txt and remove any non-cluster service principal entries within it. Make

sure that the default krbtgt and other principals you created, or were created by Kerberos by

default, are not removed by running the following: for i in `cat cluster-princ.txt`; do yes yes | kadmin.local -q "delprinc $i"; done.

c. Start the Cloudera Manager database and Cloudera Manager Server.

d. Start the Cloudera Manager Agents on the newly renamed hosts. The Agents should show a current heartbeat in Cloudera Manager.

e. Within the Cloudera Manager Admin Console recreate all the principals based on the new hostnames: a. Select Administration > Kerberos.

(16)

b. Do one of the following:

• If there are no principals listed, click the Generate Principals button.

• If there are principals listed, click the top checkbox to select all principals and click the Regenerate button.

9. If one of the hosts that was renamed has a NameNode configured with High Availability and automatic failover enabled, reconfigure the ZooKeeper failover controller znodes to reflect the new hostname.

Warning:

• Do not perform this step if you are also running JobTracker in a High Availability configuration, as clearing the hadoop-ha znode will negatively impact JobTracker HA.

• All other services, and most importantly HDFS, should not be running. a. Start ZooKeeper services.

Note: Make sure the ZooKeeper Failover Controller role is stopped within the HDFS service; start only the ZooKeeper Server role instances.

b. On one of the hosts that has a ZooKeeper Server role, log into the Zookeeper CLI to delete the Nameservice znode:

• On a package-based installation zkCli.sh is found at: /usr/lib/zookeeper/bin/zkCli.sh

• On a parcel-based installation zkCli.sh is found at:

$/opt/cloudera/parcels/CDH/lib/zookeeper/bin/zkCli.sh

a. Verify that the HA znode exists: zkCli$ ls /hadoop-ha

b. Delete the old znode: zkCli$ rmr /hadoop-ha/nameservice1

c. In the Cloudera Manager Admin Console, go to the HDFS service. d. Click the Instances tab.

e. Select Actions > Initialize High Availability State in ZooKeeper....

10. For each of the Cloudera Management Service roles (Host Monitor, Service Monitor, Reports Manager, Activity Monitor, Navigator) go to their configuration and update the Database Hostname property.

11. Start all cluster services.

12. Start the Cloudera Management Service. 13. Deploy client configurations.

Backing up Databases

Cloudera recommends that you periodically back up the databases that Cloudera Manager uses to store configuration, monitoring, and reporting data and for managed services that require a database:

• Cloudera Manager - Contains all the information about what services you have configured, their role assignments, all configuration history, commands, users, and running processes. This is a relatively small database (<100 MB), and is the most important to back up. A monitoring database contains monitoring information about service and host status. In large clusters, this database can grow large.

• Activity Monitor - Contains information about past activities. In large clusters, this database can grow large. • Reports Manager - Keeps track of disk utilization and processing activities over time. Medium-sized. • Hive Metastore - Contains Hive metadata. Relatively small.

• Sentry Server - Contains authorization metadata. Relatively small.

• Cloudera Navigator Audit Server - Contains auditing information. In large clusters, this database can grow large.

(17)

Backing Up PostgreSQL Databases

The procedure for backing up a PostgreSQL database is the same whether you are using an embedded or external database:

1. Log in to the host where the Cloudera Manager Server is installed. 2. Run the following command as root:

cat /etc/cloudera-scm-server/db.properties. The db.properties file contains:

# Auto-generated by scm_prepare_database.sh # Mon Jul 27 22:36:36 PDT 2011 com.cloudera.cmf.db.type=postgresql com.cloudera.cmf.db.host=host:7432 com.cloudera.cmf.db.name=scm com.cloudera.cmf.db.user=scm com.cloudera.cmf.db.password=NnYfWIjlbk

3. Run the following command as root using the parameters from the preceding step:

# pg_dump -h host -p 7432 -U scm > /tmp/scm_server_db_backup.$(date +%Y%m%d)

4. Enter the password specified for the com.cloudera.cmf.db.password property on the last line of the db.properties file. If you are using the embedded database, Cloudera Manager generated the password

for you during installation. If you are using an external database, enter the appropriate information for your database.

Backing Up MySQL Databases

To back up the MySQL database, run the mysqldump command on the MySQL host, as follows:

$ mysqldump -hhostname -uusername -ppassword database > /tmp/database-backup.sql

For example, to back up the Activity Monitor database amon on the local host as the root user, with the password amon_password:

$ mysqldump -pamon_password amon > /tmp/amon-backup.sql

To back up the sample Activity Monitor database amon on remote host myhost.example.com as the root user,

with the password amon_password:

$ mysqldump -hmyhost.example.com -uroot -pcloudera amon > /tmp/amon-backup.sql

Backing Up Oracle Databases

For Oracle, work with your database administrator to ensure databases are properly backed up.

(18)

(19)

Cloudera Management Service

The Cloudera Management Service implements various management features as a set of roles:

• Activity Monitor - collects information about activities run by the MapReduce service. This role is not added by default.

• Host Monitor - collects health and metric information about hosts

• Service Monitor - collects health and metric information about services and activity information from the YARN and Impala services

• Event Server - aggregates relevant Hadoop events and makes them available for alerting and searching • Alert Publisher - generates and delivers alerts for certain types of events

• Reports Manager - generates reports that provide an historical view into disk utilization by user, user group, and directory, processing activities by user and YARN pool, and HBase tables and namespaces. This role is not added in Cloudera Express.

Cloudera Manager manages each role separately, instead of as part of the Cloudera Manager Server, for scalability (for example, on large deployments it's useful to put the monitor roles on their own hosts) and isolation. In addition, for certain editions of the Cloudera Enterprise license, the Cloudera Management Service provides the Navigator Audit Server and Navigator Metadata Server roles for Cloudera Navigator.

Displaying the Cloudera Management Service Status

1. Do one of the following:

• Select Clusters > Cloudera Management Service > Cloudera Management Service.

• On the Status tab of the Home page, in Cloudera Management Service table, click the Cloudera Management Service link.

Starting the Cloudera Management Service

Required Role:

• 1. Select Clusters > Cloudera Management Service > Cloudera Management Service. 2. Select Actions > Start.

• 1. _{On the Home page, click} _{to the right of Cloudera Management Service and select Start.} 2. Click Start to confirm. The Command Details window shows the progress of starting the roles.

3. When Command completed with n/n successful subcommands appears, the task is complete. Click Close.

Stopping the Cloudera Management Service

Required Role:

• 1. Select Clusters > Cloudera Management Service > Cloudera Management Service. 2. Select Actions > Stop.

• 1. _{On the Home page, click} _{to the right of Cloudera Management Service and select Stop.} 2. Click Stop to confirm. The Command Details window shows the progress of stopping the roles.

(20)

Restarting the Cloudera Management Service

Required Role:

• 1. Select Clusters > Cloudera Management Service > Cloudera Management Service. 2. Select Actions > Restart.

• 1.

On the Home page, click to the right of Cloudera Management Service and select Restart. 2. Click Restart to confirm. The Command Details window shows the progress of stopping and then starting

the roles.

Configuring Management Service Database Limits

Required Role:

Each Cloudera Management Service role maintains a database for retaining the data it monitors. These databases (as well as the log files maintained by these services) can grow quite large. For example, the Activity Monitor maintains data at the service level, the activity level (MapReduce jobs and aggregate activities), and at the task attempt level. Limits on these data sets are configured when you create the management services, but you can modify these parameters through the Configuration settings in the Cloudera Manager Admin Console. For example, the Event Server lets you set a total number of events to store, and Activity Monitor gives you "purge" settings (also in hours) for the data it stores.

There are also settings for the logs that these various services create. You can throttle how big the logs are allowed to get and how many previous logs to retain.

a. Select Clusters > Cloudera Management Service > Cloudera Management Service.

b. On the Status tab of the Home page, in Cloudera Management Service table, click the Cloudera Management Service link.

2. Click the Configuration tab.

3. In the left-hand column, select the Default role group for the role whose configurations you want to modify. 4. Edit the appropriate properties:

• Activity Monitor - the Purge or Expiration period properties are found in the top-level settings for the role.

• Host and Service Monitor - see Data Storage for Monitoring Data.

• Log Files - log file size settings will be under the Logs category under the role group. 5. Click Save Changes.

Adding and Starting Cloudera Navigator Roles

Required Role:

a. Select Clusters > Cloudera Management Service > Cloudera Management Service. b. Select Actions > Restart.

2. Click the Instances tab.

(21)

3. Click the Add Role Instances button. The Customize Role Assignments page displays. 4. Assign the Navigator role to a host.

a. Customize the assignment of role instances to hosts. The wizard evaluates the hardware configurations of the hosts to determine the best hosts for each role. The wizard assigns all worker roles to the same set of hosts to which the HDFS DataNode role is assigned. These assignments are typically acceptable, but you can reassign role instances to hosts of your choosing, if desired.

Click a field below a role to display a dialog containing a pageable list of hosts. If you click a field containing multiple hosts, you can also select All Hosts to assign the role to all hosts or Custom to display the pageable hosts dialog.

The following shortcuts for specifying hostname patterns are supported: • Range of hostnames (without the domain portion)

Matching Hosts Range Definition

10.1.1.1, 10.1.1.2, 10.1.1.3, 10.1.1.4 10.1.1.[1-4]

host1.company.com, host2.company.com, host3.company.com host[1-3].company.com

host07.company.com, host08.company.com, host09.company.com, host10.company.com

host[07-10].company.com

• IP addresses • Rack name

Click the View By Host button for an overview of the role assignment by hostname ranges. 5. When you are satisfied with the assignments, click Continue. The Database Setup page displays. 6. Configure database settings:

a. Choose the database type:

• Leave the default setting of Use Embedded Database to have Cloudera Manager create and configure required databases. Make a note of the auto-generated passwords.

• Select Use Custom Databases to specify external databases.

1. Enter the database host, database type, database name, username, and password for the database that you created when you set up the database.

b. Click Test Connection to confirm that Cloudera Manager can communicate with the database using the information you have supplied. If the test succeeds in all cases, click Continue; otherwise check and correct the information you have provided for the database and then try the test again. (For some servers, if you are using the embedded database, you will see a message saying the database will be created at a later step in the installation process.) The Review Changes page displays.

7. Review and accept any configuration changes (typically there are none). Click Accept. This returns you to the Instances page.

8. Check the checkboxes next to the Navigator Audit Server and Navigator Metadata Server roles. 9. Select Actions for Selected > Start and confirm Start in the pop-up.

10. Click Close.

(22)

(23)

Managing Users and Authentication

This chapter covers managing user accounts, and configuring external authentication. • Cloudera Manager User Accounts on page 23

• Configuring External Authentication on page 25

Cloudera Manager User Accounts

Required Role:

Access to Cloudera Manager features is controlled by user accounts. A user account identifies how a user is authenticated and determines what privileges are granted to the user.

When you are logged in to the Cloudera Manager Admin Console, the username you are logged in as is at the far right of the top navigation bar—for example, if you are logged in as admin you will see .

An user in the Administrator role manages user accounts through the Administration > Users page.

User Authentication

Cloudera Manager provides several mechanisms for authenticating users. You can configure Cloudera Manager to authenticate users against the Cloudera Manager database or against an external authentication service. The external authentication service can be an LDAP server (Active Directory or an OpenLDAP compatible directory), or you can specify another external service. Cloudera Manager also supports using the Security Assertion Markup Language (SAML) to enable single sign-on.

If you are using LDAP or an external service you can configure Cloudera Manager so that it can use both methods of authentication (internal database and external service), and you can determine the order in which it performs these searches. If you select an external authentication mechanism, Administrator users can always authenticate against the Cloudera Manager database. This is to prevent locking everyone out if the authentication settings are misconfigured—such as with a bad LDAP URL.

With external authentication, you can restrict login access to members of specific groups, and can specify groups whose members are automatically given Administrator access to Cloudera Manager.

Users accounts in the Cloudera Manager database page show Cloudera Manager in the User Type column. User accounts in an LDAP directory or other external authentication mechanism show External in the User Type column.

User Roles

A user's role determines the Cloudera Manager features visible to the user and the actions the user can perform. All the tasks in the Cloudera Manager documentation indicate which role is required to perform the task.

Note: Currently there is no indication in the Cloudera Manager Admin Console of the role a logged in user is assigned to. To determine your role, contact a user that has the Administrator role.

A user account can be assigned one of the following roles:

• Read-Only - Allows the user to view service and monitoring information but cannot add services or take any actions that affect the state of the cluster.

• Limited Operator - Allows the user to view service and monitoring information and decommission hosts (except hosts running Cloudera Management Service roles), but cannot add services or take any other actions that affect the state of the cluster.

(24)

• Operator - Allows the user to view service and monitoring information, stop, start, and restart clusters, services, and roles (except the Cloudera Management Service and roles), decommission and recommission hosts (except hosts running Cloudera Management Service roles), and decommission and recommission roles (except Cloudera Management Service roles), but cannot add services, roles, or hosts, or take any other actions that affect the state of the cluster.

• Configurator - Allows the user to perform all Operator operations, configure services (except the Cloudera Management Service), enter and exit maintenance mode, and manage dashboards (including Cloudera Management Service dashboards).

• Administrator - Allows the user to add, change, delete, and configure services, roles, and hosts and administer user accounts. Even if you are using an external authentication mechanism for user authentication, users with Administrator privileges can log in to Cloudera Manager using their local Cloudera Manager username and password. (This prevents the system from locking everyone out if the external authentication settings get misconfigured.)

The full set of roles are available with Cloudera Enterprise; Cloudera Express supports only the Read-Only and Administrator roles.

Changing the Logged-In Internal User Password

1. Right-click the logged-in username at the far right of the top navigation bar and select Change Password. 2. Enter the current password, and a new password twice and then click Update.

Adding an Internal User Account

1. Select Administration > Users. 2. Click the Add User button. 3. Enter a username and password.

4. In the Role drop-down, select a role for the new user. 5. Click Add.

Assigning User Roles

1. Select Administration > Users.

2. Check the checkbox next to one or more usernames. 3. Select Actions for Selected > Assign User Roles. 4. In the drop-down, select the role.

5. Click the Assign Role button.

Changing an Internal User Account Password

2. Click the Change Password button next to a username with User Type Cloudera Manager. 3. Type the new password and repeat it to confirm.

4. Click the Update button to make the change.

Deleting Internal User Accounts

2. Check the checkbox next to one or more usernames with User Type Cloudera Manager. 3. Select Actions for Selected > Delete.

4. Click the OK button. (There is no confirmation of the action.)

(25)

Configuring External Authentication

Required Role:

Important: This feature is available only with a Cloudera Enterprise license. For other licenses, the following applies:

• Cloudera Express - The feature is not available.

• Cloudera Enterprise Data Hub Edition Trial - The feature is available until you end the trial or the trial license expires.

To obtain a license for Cloudera Enterprise, please fill in this form or call 866-843-7207. After you install a Cloudera Enterprise license, the feature will be available.

Cloudera Manager supports user authentication against an internal database and against an external service. The following sections describe how to configure the supported external services.

Configuring Authentication Using Active Directory

2. In the left-hand column, select the External Authentication category.

3. In the Authentication Backend Order field, select the order in which Cloudera Manager should attempt its authentication. You can choose to authenticate users using just one of the methods (using Cloudera Manager's own database is the default), or you can set it so that if the user cannot be authenticated by the first method, it will attempt using the second method.

4. For External Authentication Type, select Active Directory.

5. In the LDAP URL property, provide the URL of the Active Directory server.

6. In the Active Directory NT Domain property, provide the NT domain to authenticate against.

7. In the LDAP User Groups property, optionally provide a comma-separated list of case-sensitive LDAP group names. If this list is provided, only users who are members of one or more of the groups in the list will be allowed to log into Cloudera Manager. If this property is left empty, all authenticated LDAP users will be able to log into Cloudera Manager. For example, if there is a group called

CN=ClouderaManagerUsers,OU=Groups,DC=corp,DC=com, add the group name ClouderaManagerUsers

to the LDAP User Groups list to allow members of that group to log in to Cloudera Manager.

8. To automatically assign a role to users when they log in, provide a comma-separated list of LDAP group names in the following properties:

• LDAP Administrator Groups • LDAP Configurator Groups • LDAP Operator Groups

• LDAP Limited Operator Groups

If you specify groups in these properties, users must also be a member of at least one of the groups specified in the LDAP User Groups property or they will not be allowed to log in. If these properties are left empty, users will be assigned to the Read-Only role and any other role assignment must be performed manually by an Administrator.

Configuring Authentication Using an OpenLDAP-compatible Server

For an OpenLDAP-compatible directory, you have several options for searching for users and groups:

• You can specify a single base Distinguished Name (DN) and then provide a "Distinguished Name Pattern" to use to match a specific user in the LDAP directory.

• Search filter options let you search for a particular user based on somewhat broader search criteria – for example Cloudera Manager users could be members of different groups or organizational units (OUs), so a

(26)

single pattern won't find all those users. Search filter options also let you find all the groups to which a user belongs, to help determine if that user should have login or admin access.

4. For External Authentication Type, select LDAP.

5. In the LDAP URL property, provide the URL of the LDAP server and (optionally) the base Distinguished Name (DN) (the search base) as part of the URL — for example ldap://ldap-server.corp.com/dc=corp,dc=com. 6. If your server does not allow anonymous binding, provide the user DN and password to be used to bind to

the directory. These are the LDAP Bind User Distinguished Name and LDAP Bind Password properties. By default, Cloudera Manager assumes anonymous binding.

7. To use a single "Distinguished Name Pattern", provide a pattern in the LDAP Distinguished Name Pattern property.

Use {0} in the pattern to indicate where the username should go. For example, to search for a distinguished

name where the uid attribute is the username, you might provide a pattern similar to

uid={0},ou=People,dc=corp,dc=com. Cloudera Manager substitutes the name provided at login into this

pattern and performs a search for that specific user. So if a user provides the username "foo" at the Cloudera Manager login page, Cloudera Manager will search for the DN uid=foo,ou=People,dc=corp,dc=com.

If you provided a base DN along with the URL, the pattern only needs to specify the rest of the DN pattern. For example, if the URL you provide is ldap://ldap-server.corp.com/dc=corp,dc=com, and the pattern

is uid={0},ou=People, then the search DN will be uid=foo,ou=People,dc=corp,dc=com.

8. You can also search using User and/or Group search filters, using the LDAP User Search Base, LDAP User Search Filter, LDAP Group Search Base and LDAP Group Search Filter settings. These allow you to combine a base DN with a search filter to allow a greater range of search targets.

For example, if you want to authenticate users who may be in one of multiple OUs, the search filter mechanism will allow this. You can specify the User Search Base DN as dc=corp,dc=com and the user search filter as uid={0}. Then Cloudera Manager will search for the user anywhere in the tree starting from the Base DN.

Suppose you have two OUs—ou=Engineering and ou=Operations—Cloudera Manager will find User "foo"

if it exists in either of these OUs, that is, uid=foo,ou=Engineering,dc=corp,dc=com or uid=foo,ou=Operations,dc=corp,dc=com.

You can use a user search filter along with a DN pattern, so that the search filter provides a fallback if the DN pattern search fails.

The Groups filters let you search to determine if a DN or username is a member of a target group. In this case, the filter you provide can be something like member={0} where {0} will be replaced with the DN of the

user you are authenticating. For a filter requiring the username, {1} may be used, as memberUid={1}. This

will return a list of groups the user belongs to, which will be compared to the list in the group properties discussed in step 8 of Configuring Authentication Using Active Directory on page 25.

Configuring Cloudera Manager to Use LDAPS

If the LDAP server certificate has been signed by a trusted Certificate Authority (that is, VeriSign, GeoTrust, and so on), steps 1 and 2 below may not be necessary.

1. Copy the CA certificate file to the Cloudera Manager Server host.

2. Import the CA certificate(s) from the CA certificate file to the local truststore. The default truststore is located in the $JAVA_HOME/jre/lib/security/cacerts file. This contains the default CA information shipped with

the JDK. Create an alternate default file called jssecacerts in the same location as the cacerts file. You can now safely append CA certificates for any private or public CAs not present in the default cacerts file,

while keeping the original file intact.

(27)

For our example, we will follow this recommendation by copying the default cacerts file into the new

jssecacerts file, and then importing the CA certificate to this alternate truststore. $ cp $JAVA_HOME/jre/lib/security/cacerts \

$JAVA_HOME/jre/lib/jssecacerts

$ /usr/java/latest/bin/keytool -import -alias nt_domain_name \

-keystore /usr/java/latest/jre/lib/security/jssecacerts -file path_to_cert

Note:

• The default password for the cacerts store is changeit. • The alias can be any name (not just the domain name).

3. Configure the LDAP URL property to use ldaps://ldap_server instead of ldap://ldap_server.

Configuring Authentication Using an External Program

You can configure Cloudera Manager to use an external authentication program of your own choosing. Typically, this may be a custom script that interacts with a custom authentication service. Cloudera Manager will call the external program with the username as the first command line argument. The password is passed over stdin.

Cloudera Manager assumes the program will return the following exit codes identifying the user role for a successful authentication: • 0 - Read-Only • 1 - Administrator • 2 - Limited Operator • 3 - Operator • 4 - Configurator

and a negative value is returned for a failure to authenticate. To configure authentication using an external program: 1. Select Administration > Settings.

4. For External Authentication Type, select External Program.

5. Provide a path to the external program in the External Authentication Program Path property.

Configuring Authentication Using SAML

Cloudera Manager supports the Security Assertion Markup Language (SAML), an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider (IDP) and a service provider (SP). The SAML specification defines three roles: the principal (typically a user), the IDP, and the SP. In the use case addressed by SAML, the principal (user agent) requests a service from the service provider. The service provider requests and obtains an identity assertion from the IDP. On the basis of this assertion, the SP can make an access control decision—in other words it can decide whether to perform some service for the connected principal.

The primary SAML use case is called web browser single sign-on (SSO). A user wielding a user agent (usually a web browser) requests a web resource protected by a SAML SP. The SP, wishing to know the identity of the requesting user, issues an authentication request to a SAML IDP through the user agent. In the context of this terminology, Cloudera Manager operates as a SP. This topic discusses the Cloudera Manager part of the

(28)

configuration process; it assumes that you are familiar with SAML and SAML configuration in a general sense, and that you have a functioning IDP already deployed.

Note:

• Cloudera Manager supports both SP- and IDP-initiated SSO.

• The logout action in Cloudera Manager will send a single-logout request to the IDP.

• SAML authentication has been tested with specific configurations of SiteMinder and Shibboleth. While SAML is a standard, there is a great deal of variability in configuration between different IDP products, so it is possible that other IDP implementations, or other configurations of SiteMinder and Shibboleth, may not interoperate with Cloudera Manager.

• To bypass SSO if SAML configuration is incorrect or not working, you can login via a Cloudera Manager local account using the URL: http://cm_host:7180/cmf/localLogin

Setting up Cloudera Manager to use SAML requires the following steps.

Preparing Files

You will need to prepare the following files and information, and provide these to Cloudera Manager: • A Java keystore containing a private key for Cloudera Manager to use to sign/encrypt SAML messages. • The SAML metadata XML file from your IDP. This file must contain the public certificates needed to verify

the sign/encrypt key used by your IDP per the SAML Metadata Interoperability Profile • The entity ID that should be used to identify the Cloudera Manager instance

• How the user ID is passed in the SAML authentication response: – As an attribute. If so, what identifier is used.

– As the NameID.

• The method by which the Cloudera Manager role will be established: – From an attribute in the authentication response:

– What identifier will be used for the attribute – What values will be passed to indicate each role – From an external script that will be called for each use:

– The script takes user ID as $1

– The script sets an exit code to reflect the assigned role: – 0 - Administrator

– 1 - Read-Only – 2 - Limited Operator – 3 - Operator

– 4 - Configurator

and a negative value is returned for a failure to authenticate.

Configuring Cloudera Manager

Required Role:

3. Set the External Authentication Type property to SAML (the Authentication Backend Order property is ignored for SAML).

4. Set the Path to SAML IDP Metadata File property to point to the IDP metadata file.

(29)

5. Set the Path to SAML Keystore File property to point to the Java keystore prepared earlier. 6. In the SAML Keystore Password property, set the keystore password.

7. In the Alias of SAML Sign/Encrypt Private Key property, set the alias used to identify the private key for Cloudera Manager to use.

8. In the SAML Sign/Encrypt Private Key Password property, set the private key password. 9. Set the SAML Entity ID property if:

• There is more than one Cloudera Manager instance being used with the same IDP (each instance needs a different entity ID).

• Entity IDs are assigned by organizational policy.

10. In the Source of User ID in SAML Response property, set whether the user ID will be obtained from an attribute or the NameID.

11. If an attribute will be used, set the attribute name in the SAML attribute identifier for user ID property. The default value is the normal OID used for user IDs and so may not need to be changed.

12. In the SAML Role assignment mechanism property, set whether the role assignment will be done from an attribute or an external script.

• If an attribute will be used:

– In the SAML attribute identifier for user role property, set the attribute name if necessary. The default value is the normal OID used for OrganizationalUnits and so may not need to be changed.

– In the SAML Attribute Values for Roles property, set which attribute values will be used to indicate the user role.

• If an external script will be used, set the path to that script in the Path to SAML Role Assignment Script property. Make sure that the script is executable (an executable binary is fine - it doesn’t need to be a shell script).

13. Save the changes. Cloudera Manager will run a set of validations that ensure it can find the metadata XML and the keystore, and that the passwords are correct. If you see a validation error, correct the problem before proceeding.

14.Restart the Cloudera Manager Server.

Configuring the IDP

After the Cloudera Manager Server is restarted, it will attempt to redirect to the IDP login page instead of showing the normal CM page. This may or may not succeed, depending on how the IDP is configured. In either case, the IDP will need to be configured to recognize CM before authentication will actually succeed. The details of this process are specific to each IDP implementation - refer to your IDP documentation for details.

1. Download the Cloudera Manager’s SAML metadata XML file from http://hostname:7180/saml/metadata.

2. Inspect the metadata file and ensure that any URLs contained in the file can be resolved by users’ web browsers. The IDP will redirect web browsers to these URLs at various points in the process. If the browser cannot resolve them, authentication will fail. If the URLs are incorrect, you can manually fix the XML file or set the Entity Base URL in the CM configuration to the right value, and then re-download the file.

3. Provide this metadata file to your IDP using whatever mechanism your IDP provides.

4. Ensure that the IDP has access to whatever public certificates are necessary to validate the private key that was provided to Cloudera Manager earlier.

5. Ensure that the IDP is configured to provide the User ID and Role using the attribute names that Cloudera Manager was configured to expect, if relevant.

6. Ensure the changes to the IDP configuration have taken effect (a restart may be necessary).

Verifying Authentication and Authorization

1. Return to the Cloudera Manager Admin Console and refresh the login page.

2. Attempt to log in with credentials for a user that is entitled. The authentication should complete and you should see the Home page.

(30)

3. If authentication fails, you will see an IDP provided error message. Cloudera Manager is not involved in this part of the process, and you must ensure the IDP is working correctly to complete the authentication. 4. If authentication succeeds but the user is not authorized to use Cloudera Manager, they will be taken to an

error page by Cloudera Manager that explains the situation. If an user who should be authorized sees this error, then you will need to verify their role configuration, and ensure that it is being properly communicated to Cloudera Manager, whether by attribute or external script. The Cloudera Manager log will provide details on failures to establish a user’s role. If any errors occur during role mapping, Cloudera Manager will assume the user is unauthorized.

(31)

Configuring TLS Security for Cloudera Manager

Important:

• Cloudera strongly recommends that you set up a fully-functional CDH cluster and Cloudera Manager before you begin configuring it to use TLS.

• Once Level 3 TLS is configured, if you want to add new hosts running Agents, you must manually deploy the Cloudera Manager Agent and daemon packages for your platform, issue a new certificate for the host, configure /etc/cloudera-scm-agent/config.ini to use SSL/TLS and then bring

the host online.

Conversely, you can disable TLS to add the host, configure the new host for TLS, then re-enable with the proper configuration in place. Either approach is valid, based on your needs.

Transport Layer Security (TLS) provides encryption and authentication in the communications between the Cloudera Manager Server and Agents. Encryption prevents snooping of communications, and authentication helps prevent malicious Servers or Agents from causing problems in your cluster. Cloudera Manager supports three levels of TLS security:

• Level 1 (Good) - Encrypted communications between the Server and Agents only; no authentication of Server and Agents. See Configuring TLS Encryption only for Cloudera Manager on page 31.

• Level 2 (Better) - Encrypted communications and authentication of Server to Agents and users; no authentication of Agents to Server. See Configuring TLS Authentication of Server to Agents on page 33. • Level 3 (Best) - Encrypted communications, authentication of Server to Agents, and authentication of Agents

to Server. See Configuring TLS Authentication of Agents to Server on page 37.

To enable TLS encryption for all connections between your Web browser running the Cloudera Manager Admin Console and the Cloudera Manager Server, see Configuring TLS Encryption for Cloudera Manager Admin Console

on page 38.

Configuring TLS Encryption only for Cloudera Manager

Required Role:

Use the keytool to manage the public keys and certificates for the Cloudera Manager Server. Before configuring

TLS security for Cloudera Manager, create a keystore, as described in the documentation at the preceding link. For example, you might use a command similar to the following:

keytool -genkey -alias jetty -keystore truststore

Step 1: Create a Cloudera Manager Server certificate.

Warning: You must use an Oracle JDK keytool.

1. Use keytool to generate a certificate for the Cloudera Manager Server. For example:

$ keytool -validity 180 -keystore <path-to-keystore> -alias jetty -genkeypair -keyalg RSA

• The -validity option specifies the certificate lifetime in number of days. If no validity value is specified,

the default value is used. The default varies, but is often 90 days.

(32)

• The <path-to-keystore> must be a path to where you want to save the keystore file, and where the Cloudera Manager Server host can access.

2. When prompted by keytool, create a password for the keystore. Save the password in a safe place.

3. When prompted by keytool, fill in the answers accurately to the questions to describe you and your company.

The most important answer is the CN value for the question "What is your first and last name?" The CN must match the fully-qualified domain name (FQDN) or IP address of the host where the Server is running. For example, cmf.company.com or 192.168.123.101.

Important: For the CN value, be sure to use a FQDN if possible, or a static IP address that will not change. Do not specify an IP address that will change periodically. When Agents connect to the server using TLS, they check whether the key uses the same name as the one they are using to connect to the server. If the names do not match, Agents do not heartbeat.

Step 2: Enable TLS encryption and specify Server keystore properties.

1. Log into the Cloudera Manager Admin Console. 2. Select Administration > Settings.

3. Click the Security category.

4. Configure the following TLS settings: Description Setting

Enable TLS encryption between the Server and Agents. Use TLS Encryption for

Agents

The full filesystem path to the keystore file. Enable TLS encryption between the Server and Agents.

Path to TLS Keystore File

The password for keystore. Keystore Password

5. Click Save Changes to save the settings.

Step 3: Enable and configure TLS on the Agent hosts.

To enable and configure TLS, you must specify values for the TLS properties in the

/etc/cloudera-scm-agent/config.ini configuration file on all Agent hosts.

1. On the Agent host, open the /etc/cloudera-scm-agent/config.ini configuration file:

2. Edit the following property in the /etc/cloudera-scm-agent/config.ini configuration file.

Specify 1 to enable TLS on the Agent, or 0 (zero) to disable TLS.

use_tls

3. Repeat these steps on every Agent host.

Step 4: Restart the Cloudera Manager Server.

Note: Perform this step only if you are using a self-signed server certificate.

Restart the Cloudera Manager Server with the following command to activate the TLS configuration settings.

$ sudo service cloudera-scm-server restart

(33)

Step 5: Restart the Cloudera Manager Agents.

On every Agent host, restart the Agent:

$ sudo service cloudera-scm-agent restart

Step 6: Verify that the Server and Agents are communicating.

In the Cloudera Manager Admin Console, open the Hosts page. If the Agents heartbeat successfully, TLS encryption is working properly.

Configuring TLS Authentication of Server to Agents

Required Role:

This is the second highest level of TLS security and requires that you provide a server certificate for the Server that is signed through a chain to a trusted root CA. You must also provide the certificate of the Certificate Authority (CA) that signed the Server's server certificate. If you are not working in a production environment, you can also use a self-signed server certificate.

Note: If the Server's server certificate or the associated CA certificate is missing or expired, the Agents do not allow communications with the Server.

Step 1: Configure TLS encryption.

If you have not already done so, you must configure TLS encryption to use this second level of security. For instructions, see Configuring TLS Encryption only for Cloudera Manager on page 31.

Step 2: Provide the Server's server certificate and CA certificate.

If you want to use a Certificate Authority-signed server certificate, you can use keytool to request a server

certificate from an existing CA, you can skip down to Using a CA-signed server certificate on page 33. Alternatively, if you want to generate your own self-signed server certificate, you can use keytool to generate a public

certificate for the Server, see Using a self-signed server certificate on page 35.

Using a CA-signed server certificate

1. Generate a new RSA key:

Use keytool provided by the Java SDK to create a new keystore containing a keypair for the Cloudera Manager

server. Replace the

$ keytool -validity 180 -keystore cm_keystore.jks -alias jetty -genkeypair -keyalg RSA

Enter keystore password: Re-enter new password:

What is your first and last name? [Unknown]: host_1.example.com

What is the name of your organizational unit? [Unknown]: Support

What is the name of your organization? [Unknown]: Cloudera

What is the name of your City or Locality? [Unknown]: London

What is the name of your State or Province? [Unknown]:

What is the two-letter country code for this unit? [Unknown]: GB

Is CN=host_1.example.com, OU=Support, O=Cloudera, L=London, ST=Unknown, C=GB correct?

(34)

[no]: yes

Enter key password for <jetty>

(RETURN if same as keystore password):

2. Create a Certificate Signing Request (CSR):

Use the key created in the previous step to create a CSR for the Cloudera Manager server.

$ keytool -certreq -alias jetty -keystore cm_keystore.jks > jetty.csr Enter keystore password:

3. Request a new server certificate:

To request a certificate from a recognised Certificate Authority (CA), provide the CSR generated in step 2. The example below uses a private CA created using OpenSSL.

$ openssl ca -config openssl.cnf -out jetty.crt -infiles jetty.csr Using configuration from openssl.cnf

Enter pass phrase for cakey.pem:

Check that the request matches the signature Signature ok

<--SNIP-->

Certificate is to be certified until Apr 19 10:49:41 2024 GMT (3650 days) Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries

Data Base Updated

4. Import CA trust certificates into the Cloudera Manager keystore:

Import the root and intermediate CA certificates to the keystore created in step 1. Generate a new RSA key.

$ keytool -import -keystore cm_keystore.jks -alias int_CA -file intermediate.crt Enter keystore password:

Owner: CN=COE Intermediate Test CA, OU=Customer Operations, O=Cloudera, ST=London, C=GB

Issuer: CN=COE Root Test CA, OU=Customer Operations, O=Cloudera, L=Shoreditch, ST=London, C=GB

Serial number: 1

Valid from: Tue Apr 22 02:02:26 PDT 2014 until: Wed Apr 22 02:02:26 PDT 2015 <--SNIP-->

Trust this certificate? [no]: yes Certificate was added to keystore

$ keytool -import -keystore cm_keystore.jks -alias root_CA -file root.crt Enter keystore password:

Owner: CN=COE Root Test CA, OU=Customer Operations, O=Cloudera, L=Shoreditch, ST=London, C=GB

Issuer: CN=COE Root Test CA, OU=Customer Operations, O=Cloudera, L=Shoreditch, ST=London, C=GB

Serial number: 928f80538cdfe523

Valid from: Tue Apr 22 01:58:53 PDT 2014 until: Sun Apr 21 01:58:53 PDT 2019 <--SNIP-->

Trust this certificate? [no]: yes Certificate was added to keystore

5. Import certificate into Cloudera Manager keystore:

Cloudera Manager Administration Guide

Table of Contents

About this Guide...7

Managing the Cloudera Manager Server and Agents...9

Cloudera Management Service...19

Managing Users and Authentication...23

Configuring TLS Security for Cloudera Manager...31

Upgrading Cloudera Manager...43

Other Cloudera Manager Settings...71

About this Guide

Managing the Cloudera Manager Server and Agents

Starting, Stopping, and Restarting the Cloudera Manager Server

Configuring Cloudera Manager Server Ports

Moving the Cloudera Manager Server to a New Host

Starting, Stopping, and Restarting Cloudera Manager Agents

Configuring Cloudera Manager Agents

Viewing Cloudera Manager Server and Agent Logs

Changing Hostnames

Backing up Databases

Backing Up PostgreSQL Databases

Backing Up MySQL Databases

Backing Up Oracle Databases

Cloudera Management Service

Managing Users and Authentication

Cloudera Manager User Accounts

Changing the Logged-In Internal User Password

Adding an Internal User Account

Assigning User Roles

Changing an Internal User Account Password

Deleting Internal User Accounts

Configuring External Authentication

Configuring Authentication Using Active Directory

Configuring Authentication Using an OpenLDAP-compatible Server

Configuring Authentication Using an External Program

Configuring Authentication Using SAML

Preparing Files

Configuring Cloudera Manager

Configuring the IDP

Verifying Authentication and Authorization

Configuring TLS Security for Cloudera Manager

Configuring TLS Encryption only for Cloudera Manager

Step 1: Create a Cloudera Manager Server certificate.

Step 2: Enable TLS encryption and specify Server keystore properties.

Step 3: Enable and configure TLS on the Agent hosts.

Step 4: Restart the Cloudera Manager Server.

Step 5: Restart the Cloudera Manager Agents.

Step 6: Verify that the Server and Agents are communicating.

Configuring TLS Authentication of Server to Agents

Step 1: Configure TLS encryption.

Step 2: Provide the Server's server certificate and CA certificate.

Using a CA-signed server certificate