Whereas upstream Istio takes a single tenant approach, Red Hat OpenShift Service Mesh supports multiple independent control planes within the cluster. Red Hat OpenShift Service Mesh uses a multitenant operator to manage the control plane lifecycle.
Red Hat OpenShift Service Mesh installs a multitenant control plane by default. You specify the projects that can access the Service Mesh, and isolate the Service Mesh from other control plane instances.
Multitenancy versus cluster-wide installations
The main difference between a multitenant installation and a cluster-wide installation is the scope of privileges used by the control plane deployments, for example, Galley and Pilot. The components no longer use cluster-scoped Role Based Access Control (RBAC) resource
Every project in the
members list will have a
RoleBinding for each service account associated with the control plane deployment and each control plane deployment will only watch those member projects. Each member project has a
maistra.io/member-of label added to it, where the
member-of value is the project containing the control plane installation.
Red Hat OpenShift Service Mesh configures each member project to ensure network access between itself, the control plane, and other member projects. The exact configuration differs depending on how OpenShift Container Platform software-defined networking (SDN) is configured. See About OpenShift SDN for additional details.
If the OpenShift Container Platform cluster is configured to use the SDN plug-in:
NetworkPolicy: Red Hat OpenShift Service Mesh creates a
NetworkPolicy resource in each member project allowing ingress to all pods from the other members and the control plane. If you remove a member from Service Mesh, this
NetworkPolicy resource is deleted from the project.
This also restricts ingress to only member projects. If you require ingress from non-member projects, you need to create a
NetworkPolicy to allow that traffic through.
Multitenant: Red Hat OpenShift Service Mesh joins the
NetNamespace for each member project to the
NetNamespace of the control plane project (the equivalent of running
oc adm pod-network join-projects --to control-plane-project member-project). If you remove a member from the Service Mesh, its
NetNamespace is isolated from the control plane (the equivalent of running
oc adm pod-network isolate-projects member-project).
Subnet: No additional configuration is performed.
Cluster scoped resources
Upstream Istio has two cluster scoped resources that it relies on. The
MeshPolicy and the
ClusterRbacConfig. These are not compatible with a multitenant cluster and have been replaced as described below.
ServiceMeshPolicy replaces MeshPolicy for configuration of control-plane-wide authentication policies. This must be created in the same project as the control plane.
ServicemeshRbacConfig replaces ClusterRbacConfig for configuration of control-plane-wide role based access control. This must be created in the same project as the control plane.