After you configure a cross-realm trust relationship for clusters for which Kerberos authentication is enabled, the clusters can access each other.

Limits

A cross-realm trust relationship can be configured for clusters for which Kerberos authentication is enabled in EMR V3.37.1 or a later minor version, or EMR V5.3.1 or a later minor version.

Procedure

  1. Step 1: Make preparations
  2. Step 2: Add principals for cross-realm authentication
  3. Step 3: Modify configurations in the krb5.conf file on Cluster-A
  4. Step 4: Access services in Cluster-B

Step 1: Make preparations

This topic provides an example, in which services in Cluster-B are accessed from Cluster-A. Cluster-A and Cluster-B belong to different realms. After Cluster-A obtains the Ticket Granting Ticket (TGT) that is issued by the key distribution center (KDC) of Cluster-A, you can access the services in Cluster-B from Cluster-A. The cross-realm trust configured in this topic is a one-way trust. In this case, you cannot access the services in Cluster-A from Cluster-B. To access the services in Cluster-A from Cluster-B, exchange the configuration entities and perform the steps that are described in this topic.

On the emr-header-1 node of each cluster, run the hostname command to obtain the hostname. Then, obtain the realm from the krb5.conf file that is stored in the /etc/ directory of each emr-header-1 node. Hostnames and realms of Cluster-A and Cluster-B:
  • Cluster-A
    • Hostname: emr-header-1.cluster-1234
    • Realm: EMR.1234.COM
  • Cluster-B
    • Hostname: emr-header-1.cluster-6789
    • Realm: EMR.6789.COM

Step 2: Add principals for cross-realm authentication

  1. Log on to Cluster-A in SSH mode. For more information, see Log on to a cluster.
  2. Run the following command on the emr-header-1 node of Cluster-A as the root user to add a principal:
    sh /usr/lib/has-current/bin/admin-local.sh /etc/ecm/has-conf -k /etc/ecm/has-conf/admin.keytab
    admin.local: addprinc -pw 123456 krbtgt/EMR.6789.COM@EMR.1234.COM
    Configurations in the preceding command:
    • 123456: the initial password. You can change the password.
    • EMR.1234.COM: the realm of Cluster-A.
    • EMR.6789.COM: the realm of Cluster-B.
  3. On the emr-header-1 node of Cluster-B, repeat 1 to 2 to add a principal.

Step 3: Modify configurations in the krb5.conf file on Cluster-A

  1. Run the following command to modify configurations in the krb5.conf file on the emr-header-1 node of Cluster-A:
    vim /etc/krb5.conf
    Modify the [realms], [domain_realm], and [capaths] parameters. Example:
    [libdefaults]
        kdc_realm = EMR.1234.COM
        default_realm = EMR.1234.COM
        udp_preference_limit = 4096
        kdc_tcp_port = 88
        kdc_udp_port = 88
        dns_lookup_kdc = false
    [realms]
        EMR.1234.COM = {
            kdc = 10.81.**.**:88
        }
        EMR.6789.COM = {
            kdc = 10.81.**.**:88
        }
    [domain_realm]
        .cluster-1234 = EMR.1234.COM
        .cluster-6789 = EMR.6789.COM
    [capaths]
        EMR.1234.COM = {
           EMR.6789.COM = .
        }
        EMR.6789.COM = {
           EMR.1234.COM = .
        }
    Note 10.81.**.** in the value of the kdc parameter is the internal IP address of the node on which the KDC is deployed.
  2. Synchronize the new configurations in the krb5.conf file to other nodes of Cluster-A.
  3. Copy the long domain names in the hosts file that is stored in the /etc/ directory of Cluster-B to the hosts file that is stored in the /etc/ directory of each node of Cluster-A. The long domain names are in the format of emr-xxx-x.cluster-xxx.
    10.**.**.**  emr-worker-1.cluster-xxx
    10.**.**.**  emr-worker-2.cluster-xxx
    10.**.**.**  emr-header-1.cluster-xxx
    Note
    • If you want to run a job on Cluster-A to access Cluster-B, you must restart YARN first.
    • You must copy the long domain names in the hosts file of Cluster-B to the hosts file in each node of Cluster-A.

Step 4: Access services in Cluster-B

In Cluster-A, use the Kerberos keytab file to access the services in Cluster-B.

For example, if you want to access HDFS in Cluster-B, add a principal required for a test and export the keytab file. For more information, see Configure MIT Kerberos authentication. In the following example, the keytab file of the test user is used:
kinit -kt test.keytab test@EMR.1234.COM
hadoop fs -ls hdfs://emr-header-1.cluster-6789:9000/
Found 6 items
drwxr-xr-x   - hadoop    hadoop          0 2021-08-27 10:10 hdfs://emr-header-1.cluster-6789:9000/apps
drwxrwxrwt   - hadoop    hadoop          0 2021-08-27 10:10 hdfs://emr-header-1.cluster-6789:9000/spark-history
drwxrwxrwt   - hadoop    hadoop          0 2021-08-27 10:11 hdfs://emr-header-1.cluster-6789:9000/tmp
drwxrwxrwt   - hadoop    hadoop          0 2021-08-27 10:11 hdfs://emr-header-1.cluster-6789:9000/user