Configuring Mutual Trust Between MRS Clusters for Unidirectional Access

Scenarios

When the local cluster is in security mode and needs to access resources of another cluster in security mode (without restarting the cluster), you can configure unidirectional access with cross-cluster mutual trust by referring to this section so that users in the local cluster can be used in the peer system.

The secure usage scope of users in each system is referred to as a domain. Each MRS Manager must have a unique domain name. Cross-Manager access allows users to use resources across domains.

Notes and Constraints

• This section applies to MRS 3.6.0 or later.
• A maximum of 500 mutually trusted clusters can be configured for a cluster.

Impact on the System

• Once cross-cluster mutual trust is configured, users from an external system can be used in the local system. System administrators should regularly review user permissions in Manager to ensure compliance with enterprise service and security requirements.
• If you set up mutual trust between clusters, affected services need to be restarted and services will be interrupted.
• After cross-cluster mutual trust is configured, internal Kerberos users krbtgt/Local cluster domain name@External cluster domain name and krbtgt/External cluster domain name@Local cluster domain name are added to the two mutually trusted clusters. The internal users cannot be deleted. System administrators need to change the passwords periodically based on enterprise service and security requirements. The passwords of these four users in the two systems must be the same. For details, see Changing the Passwords for MRS Cluster Component Running Users. When the passwords are changed, the connectivity between cross-cluster service applications may be affected.
• After cross-cluster mutual trust is configured, download and install the client again for each cluster. Otherwise, the trust relationship cannot be used for inter-cluster access.
• After cross-cluster mutual trust is configured, check that the system is working correctly. Then, confirm that users in the local system can access resources from the peer system. For details, see Configuring User Permissions for Mutually Trusted MRS Clusters.

Prerequisites

• The system administrator has clarified the service requirements and planned the domain names for the systems. A domain name can contain uppercase letters, digits, periods (.), and underscores (_), and must start with a letter or digit. For example, DOMAINA.HW and DOMAINB.HW.
• Before configuring cross-cluster mutual trust, verify that the two MRS Manager systems have different domain names. If the domain names are identical, modify them by referring to Changing the System Domain Name of an MRS Cluster. (After modifying the domain name, you must restart the cluster for the change to take effect.) When an ECS or BMS cluster is created in MRS, a unique system domain name is randomly generated, so you generally do not need to change it.
• The two clusters do not share any host names or IP addresses.
• The system time on both clusters must be identical, and their NTP services must use the same clock source.
• If configuring mutual trust between clusters running MRS 3.3.1 or later, ensure that both clusters use the same encryption algorithms and modes.

  You can run the cat ${CONTROLLER_HOME}/inst/conf/oms-config.ini | grep "krb5_supported_enctypes" command in the MRS cluster and check the value of krb5_supported_enctypes to determine the encryption type.

  • If this parameter is left blank, the default encryption algorithm and mode are used, that is, AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96.
  • aes256-sha1,aes128-sha1 indicates that the encryption algorithm and mode are AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96.
  • aes256-sha2,aes128-sha2 indicates that the encryption algorithm and mode are AES256-CTS-HMAC-SHA384-192 AES128-CTS-HMAC-SHA256-128.
• The running status of all components in the two clusters is Normal.
• The acl.compare.shortName parameter for the ZooKeeper service across all clusters in MRS Manager must be set to the default value true. Otherwise, change the value to true and restart the ZooKeeper service.
• Both clusters must reside in the same VPC. If they are in different VPCs, create a VPC peering connection between them. For details, see VPC Peering Connection.

Procedure

1. Log in to the Manager of the peer cluster to be accessed by the local cluster.

   For details about how to log in to MRS Manager, see Accessing an MRS Cluster's Manager (Version 2.x or Earlier).

2. Choose System > Permission > Domain and Mutual Trust.
3. Modify Peer Mutual Trust Domain.

   Table 1 Related parameters

   Parameter	Description
   realm_name	Enter the domain name of the peer system.
   ip_port	Enter the KDC address of the peer system. The parameter value must follow the format IP address:Port. IP address: IP address of the node accommodating the Kerberos service in the peer system. To obtain the IP address, click the Instances tab on the KrbServer service page and check the service IP address of the KerberosServer role. Port: You can obtain the port number from the kdc_ports parameter of the KrbServer service. The default value is 21732. For example, if the Kerberos service is deployed on nodes with IP addresses 10.0.0.1 and 10.0.0.2 that have established mutual trust with the local system, the parameter value is 10.0.0.1:21732,10.0.0.2:21732. In dual-plane networking, enter the service plane IP address. If an IPv6 address is used, the IP address must be enclosed in square brackets ([]). Use commas (,) to separate the KDC addresses if the active and standby Kerberos services are deployed or multiple clusters in the peer system need to establish mutual trust with the local system.

   

   If you need to configure mutual trust for multiple MRS Manager systems, click to add a new item and set parameters. To delete unnecessary configurations, click .

4. Click OK.
5. Log in to MRS Manager of the local cluster and repeat steps Step 2 through Step 4.
6. Log in to the active management node of the local cluster as user omm, and run the following command to update the domain configuration:

   sh ${BIGDATA_HOME}/om-server/om/sbin/restart-RealmConfig.sh

   The command is successfully executed if the following information is displayed:

   Modify realm successfully. Use the new password to log into FusionInsight again.

   After the restart, some hosts and services cannot be accessed and an alarm is generated. This problem can be automatically resolved in about 1 minute after restart-RealmConfig.sh is run.

7. Log in to MRS Manager for the current cluster and restart the cluster or any instances with expired configurations.

   Confirm whether the Manager system domain name of this cluster has been modified.

   • If the system domain name is changed, choose More > Restart in the upper right corner of the home page, enter the password, select the checkbox for confirming the impact, and click OK. Wait until the cluster is restarted.
   • If the system domain name is not changed, choose More > Restart Configuration-Expired Instances in the upper right corner of the home page, enter the password, select the checkbox for confirming the impact, and click OK. Wait until the service is restarted.

     If the Doris service is installed in the cluster, choose Cluster > Services > Doris. On the Dashboard page, choose More > Restart Service in the upper right corner, enter the password, and click OK. Wait until the Doris service restarts.

8. Log out of MRS Manager and log in again. A successful login confirms that the configuration was successful.
9. Log in to the active management node as user omm and run the following command to update the configurations of the job submission client:

   sh /opt/executor/bin/refresh-client-config.sh