Enable mutual access between workloads on remote and managed control planes - Alibaba Cloud Service Mesh

This topic describes how to achieve mutual access between clusters after using the ASM remote control plane feature.

Prerequisites

You have completed all the steps in Reduce push latency using the remote control plane of ASM. In this topic, cluster-1 represents an Alibaba Cloud Container Service for Kubernetes (ACK) cluster managed by the managed control plane of ASM, and cluster-2 represents a non-ACK cluster managed by the remote control plane of ASM.
The steps in this topic require you to switch between kubeconfig files. Add the kubeconfig files for cluster-1 and cluster-2 to the same configuration file and use the kubectl config use-context command to switch between the clusters. You can also use kubecm or kubectx to manage the kubeconfig files for multiple clusters.
You have configured the cluster network and the east-west gateway, and deployed the httpbin and sleep applications in both cluster-1 and cluster-2. For more information, see Achieve multi-cluster cross-network interconnection using the ASM east-west gateway.

Step 1: Test access from cluster-1 to cluster-2

Use the kubeconfig file for cluster-1 to run the following command. This command scales the httpbin application in cluster-1 to 0 replicas for testing purposes.
```
kubectl scale deployment httpbin --replicas 0
```
Use the kubeconfig file for cluster-1 to run the following command to access the httpbin application from the sleep application in cluster-1.
```
kubectl exec deployment/sleep -it -- curl httpbin:8000/status/418
```
Expected output:
```
    -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/
        `"""`
```
The output indicates that the access is successful. The request is processed by the httpbin application in cluster-2, and the communication is encrypted using mutual Transport Layer Security (mTLS).

Step 2: Test accessing cluster-1 from cluster-2

Use the following YAML file to create the ClusterRole and ClusterRoleBinding resources in cluster-1. The remote control plane of cluster-2 uses this ClusterRole to obtain service information from cluster-1.

Expand to view the YAML file

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app: istio-reader
  name: istio-reader-clusterrole-istio-system
rules:
- apiGroups:
  - config.istio.io
  - security.istio.io
  - networking.istio.io
  - authentication.istio.io
  - rbac.istio.io
  - telemetry.istio.io
  - extensions.istio.io
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - endpoints
  - pods
  - services
  - nodes
  - replicationcontrollers
  - namespaces
  - secrets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.istio.io
  resources:
  - workloadentries
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - networking.x-k8s.io
  - gateway.networking.k8s.io
  resources:
  - gateways
  - gatewayclasses
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - discovery.k8s.io
  resources:
  - endpointslices
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - multicluster.x-k8s.io
  resources:
  - serviceexports
  verbs:
  - get
  - list
  - watch
  - create
  - delete
- apiGroups:
  - multicluster.x-k8s.io
  resources:
  - serviceimports
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - apps
  resources:
  - replicasets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - authentication.k8s.io
  resources:
  - tokenreviews
  verbs:
  - create
- apiGroups:
  - authorization.k8s.io
  resources:
  - subjectaccessreviews
  verbs:
  - create
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["create", "get", "list", "watch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app: istio-reader
  name: istio-reader-clusterrole-istio-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: istio-reader-clusterrole-istio-system
subjects:
- kind: ServiceAccount
  name: istio-reader-service-account
  namespace: istio-system

Make sure that you have configured the kubectl contexts. The context for cluster-1 must be named cluster-1, and the context for cluster-2 must be named cluster-2.
Install the istioctl tool. Make sure that the version of istioctl is compatible with your ASM version. Switch your working directory to the unzipped istio folder and run the following command.
```
# Replace <YOUR_CLUSTER1_ID> with the ID of cluster-1.
bin/istioctl create-remote-secret \
--context=cluster-1 \
--name=<YOUR_CLUSTER1_ID> | \
kubectl apply -f - --context=cluster-2
```
After you complete this step, a secret is generated in the istio-system namespace of cluster-2. The secret contains the access credential that is used to connect to cluster-1. Manage the permissions on this secret to prevent it from being leaked.
Use the kubeconfig file for cluster-1 to run the following command to change the number of replicas for the httpbin application to 1.
```
kubectl scale deployment httpbin --replicas 1
```
Use the kubeconfig file for cluster-2 to run the following command to change the number of replicas for the httpbin application to 0.
```
kubectl scale deployment httpbin --replicas 0
```

Use the kubeconfig file for cluster-2 to run the following command to test access from cluster-2 to the httpbin application in cluster-1.

kubectl exec deployment/sleep -it -- curl httpbin:8000/status/418

Expected output:

    -=[ teapot ]=-

       _...._
     .'  _ _ `.
    | ."` ^ `". _,
    \_;`"---"`|//
      |       ;/
      \_     _/
        `"""`