Cisco Panoptica workload security and runtime policies can be applied to Kubernetes multi-cluster environments.
With this, you can create policies to allow (or deny) communication between workloads in services on different clusters.
In order to do this, the Panoptica controller must be deployed on each of the clusters. Panoptica and the controller use the Istio service mesh on each cluster to discover the services running on each cluster, whether public or private. When you define communication rules, Panoptica configures the service mesh on each of the clusters to establish the connection.

Benefits

With the Panoptica controller deployed on several Kubernetes clusters, you have the following benefits:

• You can define simple, intuitive runtime policies to regulate workload activity and communication that seamlessly spans multiple clusters, without the need to configure each cluster
• You can define connections to workloads running in private services on clusters (that otherwise are unreachable from outside the cluster)
• You use the same policies, without changes, even as workloads and services dynamically start and stop, or migrate from cluster to cluster

Enable multi-cluster support on Kubernetes clusters

To enable Panoptica multi-cluster support you must deploy the Panoptica controller on each of the clusters forming the multi-cluster. That is, you must create a cluster in Panoptica for each of the clusters, and then download and install the Panoptica controller on each one.
You must also configure each cluster to support multi-cluster communication, when you create the cluster in Panoptica:

Certificates for Multi-clusters

When you use multi-clusters, you must use the same root certificate for both clusters. By default, Istio generates a self-signed root certificate and key for each cluster, which will result in root certificate mismatch and mTLS failure.

Configure certificates

Provide a path to an empty folder in the installation script. Panoptica will generate RSA key-pairs for the root and the CA, a self signed root certificate and a CA certificate signed by the root. It will be placed in the folder, and used by both clusters.

/install_bundle.sh -c <path to folder>

For example:

./install_bundle.sh -c /tmp/certs

If /tmp/certs is an empty folder, Panoptica will generate the key-pairs and certificates.
If the folder contains all the key-pairs and certificates, Panoptica will use them.