Configuring Cross-Cluster Mutual Trust Relationships

Scenario

If cluster A needs to access the resources of cluster B, the mutual trust relationship must be configured between these two clusters.

If no trust relationship is configured, resources of a cluster are available only for users in this cluster. MRS automatically assigns a unique domain name for each cluster to define the scope of resources for users.

The operations described in this section apply only to clusters of versions earlier than MRS 3.x.

For clusters of MRS 3.x or later, see Configuring Cross-Manager Mutual Trust Between Clusters.

Impact on the System

After cross-cluster mutual trust is configured, resources of a cluster become available for users in other cluster. User permission in the clusters must be regularly checked based on service and security requirements.
After cross-cluster mutual trust is configured, the KrbServer service needs to be restarted and the cluster becomes unavailable during the restart.
After cross-cluster mutual trust is configured, internal 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 clusters. The internal users cannot be deleted. The default password is Crossrealm@123.

Prerequisites

Both clusters are in the same VPC. If they are not, create a VPC peering connection between them. For details, see VPC Peering Connection.

Procedure

On the MRS management console, query all security groups of the two clusters.
- If the security groups of the two clusters are the same, go to 3.
- If the security groups of the two clusters are different, go to 2.
On the VPC management console, choose Access Control > Security Groups. On the Security Groups page, locate the row containing the target security group, click Manage Rule in the Operation column.

On the Inbound Rules tab page, click Add Rule. In the Add Inbound Rule dialog box that is displayed, configure related parameters.
- Priority: The value ranges from 1 to 100. The default value is 1, which indicates the highest priority. A smaller value indicates a higher priority.
- Action: Select Allow.
- Protocol & Port: Choose Protocols > All.
- Type: Select IPv4 or IPv6.
- Source: Select Security group and the security group of the peer cluster.
  - To add an inbound rule to the security group of cluster A, set Source to Security group and the security group of cluster B (peer cluster).
  - To add an inbound rule to the security group of cluster B, set Source to Security group and the security group of cluster A (peer cluster).
For a common cluster with Kerberos authentication disabled, perform step 1 to 2 to configure cross-cluster mutual trust. For a security cluster with Kerberos authentication enabled, after completing the preceding steps, proceed to the following steps for configuration.
Log in to MRS Manager of the two clusters separately. For details, see Accessing MRS Manager (MRS 2.x or Earlier). Click Service and check whether the Health Status of all components is Good.
- If yes, go to 4.
- If no, contact technical support personnel for troubleshooting.
Query configuration information.
1. On MRS Manager of the two clusters, choose Services > KrbServer > Instance. Query the OM IP Address of the two KerberosServer hosts.
2. Click Service Configuration. Set Type to All. Choose KerberosServer > Port in the navigation tree on the left. Query the value of kdc_ports. The default value is 21732.
3. Click Realm and query the value of default_realm.

On MRS Manager of either cluster, modify the peer_realms parameter.

**Table 1** Parameter description
Parameter	Description
realm_name	Domain name of the mutual-trust cluster, that is, the value of default_realm obtained in step 4.
ip_port	KDC address of the peer cluster. Format: IP address of a KerberosServer node in the peer cluster:kdc_port The addresses of the two KerberosServer nodes are separated by a comma. For example, if the IP addresses of the KerberosServer nodes are 10.0.0.1 and 10.0.0.2 respectively, the value of this parameter is 10.0.0.1:21732,10.0.0.2:21732.

To deploy trust relationships with multiple clusters, click to add items and specify relevant parameters. To delete an item, click .
A cluster can have trust relationships with a maximum of 16 clusters. By default, no trust relationship exists between different clusters that are trusted by a local cluster.

Click Save Configuration. In the dialog box that is displayed, select Restart the affected services or instances and click OK. If you do not select Restart the affected services or instances, manually restart the affected services or instances.

After Operation successful is displayed, click Finish.
Exit MRS Manager and log in to it again. If the login is successful, the configurations are valid.
Log in to MRS Manager of the other cluster and repeat step 5 to 7.

Follow-up Operations

After cross-cluster mutual trust is configured, the service configuration parameters are modified on MRS Manager and the service is restarted. Therefore, you need to prepare the client configuration file again and update the client.

Scenario 1:

Cluster A and cluster B (peer cluster and mutually trusted cluster) are the same type, for example, analysis cluster or streaming cluster. Follow instructions in Updating a Client (Versions Earlier Than 3.x) to update the client configuration files of cluster A and B respectively.

Update the client configuration file of cluster A.
Update the client configuration file of cluster B.

Scenario 2:

Cluster A and cluster B (peer cluster and mutually trusted cluster) are the different type. Perform the following steps to update the configuration files.

Update the client configuration file of cluster A to cluster B.
Update the client configuration file of cluster B to cluster A.
Update the client configuration file of cluster A.
Update the client configuration file of cluster B.

Log in to MRS Manager of cluster A.
Click Services, and then Download Client.
Set Client Type to Only configuration files.
Set Download to to Remote host.
Set Host IP Address to the IP address of the active Master node of cluster B, Host Port to 22, and Save Path to /tmp.
- If the default port 22 for logging in to cluster B using SSH is changed, set Host Port to a new port.
- The value of Save Path contains a maximum of 256 characters.
Set Login User to root.

If another user is used, ensure that the user has permissions to read, write, and execute the save path.
Select Password or SSH Private Key for Login Mode.
- Password: Enter the password of user root set during cluster creation.
- SSH Private Key: Select and upload the key file used for creating the cluster.
Click OK to generate a client file.

If the following information is displayed, the client file is saved. Click Close.
```
Client files downloaded to the remote host successfully.
```
If the following information is displayed, check the username, password, and security group configurations of the remote host. Ensure that the username and password are correct and an inbound rule of the SSH (22) port has been added to the security group of the remote host. And then, go to 2 to download the client again.
```
Failed to connect to the server. Please check the network connection or parameter settings.
```
Log in to the ECS of cluster B using VNC.

All images support Cloud-Init. The preset username for Cloud-Init is root, and the password is the one set during cluster creation.
Run the following command to switch to the client directory, for example, /opt/Bigdata/client:

cd /opt/Bigdata/client
Run the following command to update the client configuration of cluster A to cluster B:

sh refreshConfig.sh Client installation directory Full path of the client configuration file package

For example, run the following command:

sh refreshConfig.sh /opt/Bigdata/client /tmp/MRS_Services_Client.tar

If the following information is displayed, the configurations have been updated successfully.
```
ReFresh components client config is complete.
Succeed to refresh components client config.
```
You can also refer to method 2 in Updating a Client (Versions Earlier Than 3.x) to perform operations in 1 to 11.
Repeat step 1 to 11 to update the client configuration file of cluster B to cluster A.
Follow instructions in Updating a Client (Versions Earlier Than 3.x) to update the client configuration file of the local cluster.
- Update the client configuration file of cluster A.
- Update the client configuration file of cluster B.