Customizing Kerberos Principals
By default, the Cloudera Manager Kerberos wizard configures CDH services to use the same Kerberos principals as the default process users. For example, the hdfs principal for the HDFS service, and the hive principal for the Hive service. The advantage to this is that when Kerberos is enabled, no HDFS directory permissions need to be changed for the new principals. However, starting with Cloudera Manager 5.4, you can configure custom service principals for CDH services.
Continue reading:
Important Considerations
- Using different Kerberos principals for different services will make it easier to track the HDFS directories being accessed by each service.
- If you are using ShellBasedUnixGroupsMapping to obtain user-group mappings, ensure you have the UNIX accounts for the principals present on all hosts of the cluster.
Configuring Directory Permissions
Configure the following HDFS directories to give their corresponding custom service principals read, write and execute permissions.Service | HDFS Directory |
---|---|
Accumulo |
|
HBase | HBase Root Directory |
Hive |
|
Impala | /user/principal |
MapReduce v1 | /tmp/mapred |
Oozie | Oozie ShareLib Root Directory |
Solr | HDFS Data Directory |
Spark on YARN |
|
Sqoop2 | /user/principal |
Configuring CDH Services
The following services will require additional settings if you are using custom principals:- HDFS - If you have enabled synchronization of HDFS and Sentry permissions, add the Hive and Impala principals to the Sentry
Authorization Provider Group property.
- Go to the HDFS service.
- Click Configuration.
- Select .
- Select .
- Locate the Sentry Authorization Provider Group property and add the custom Hive and Impala principals.
- Click Save Changes.
- YARN - The principals used by YARN daemons should be part of hadoop group so that they are allowed to read JobHistory Server data.
- Impala - If you are running the Hue service with a custom principal, configure Impala to allow the Hue principal to impersonate other users.
- Go to the Impala service.
- Click Configuration.
- Select .
- Select .
- Locate the Proxy User Configuration property and add the custom Hue principal.
- Click Save Changes.
- Hive - If the Sentry service is enabled, allow the Kerberos principals used by Hive, Impala, Hue, HDFS and the Service Monitor to bypass Sentry
authorization in the Hive metastore.
- Go to the Hive service.
- Click Configuration.
- Select .
- Select .
- Locate the Bypass Sentry Authorization Users property and add the custom Hive, Impala, Hue and HDFS principals to the list.
- Click Save Changes.
- Spark on YARN - The principal used by the Spark service should be part of the spark group.
- Sentry - Allow the Hive, Impala, Hue and HDFS principals to connect to the Sentry service.
- Go to the Sentry service.
- Click Configuration.
- Search for the Allowed Connecting Users property and add the custom Hive, Impala, Hue and HDFS principals to the list.
- Search for the Admin Groups property and include the groups to which the Hive, Impala, and Hue principals belong.
- Click Save Changes.
- Cloudera Management Service - Configure the Reports Manager principal and the Navigator principal for HDFS as HDFS superusers.
- Go to the Cloudera Management Service.
- Click Configuration.
- Search for kerberos.
- Locate the Reports Manager Kerberos Principal property and set it to a principal with administrative and superuser privileges on all HDFS services.
- Locate the Navigator Kerberos Principal for HDFS property and set it to a principal with administrative and superuser privileges on all HDFS services.
- Click Save Changes.
Incompatibilities
The following features do not work with custom principals:- Llama must always use the default Kerberos principal llama.
- If you are using MapReduce v1, the Activity Monitor and Cloudera Navigator should use the same principal as the Hue service.
- If you are using the Java KeyStore KMS or KeyTrustee KMS with a custom principal, you will need to add the proxy user for the custom principal to the kms-site.xml safety valve.
For example, if you’ve replaced the default oozie principal with oozieprinc, add the hadoop.kms.proxyuser.oozieprinc.groups and hadoop.kms.proxyuser.oozieprinc.hosts properties to the kms-site.xml safety valve.