Table of Contents
A VirtualMesh represents a logical grouping of meshes for shared configuration and cross-mesh interoperability.
VirtualMeshes are used to configure things like shared trust roots (for mTLS) and federation of traffic targets (for cross-cluster networking).
Currently, VirtualMeshes can only be constructed from Istio meshes.
|meshes||core.skv2.solo.io.ObjectRef||repeated||The meshes contained in this virtual mesh.|
|mtlsConfig||networking.mesh.gloo.solo.io.VirtualMeshSpec.MTLSConfig||Configuration options for managing Mutual-TLS mTLS in a virtual mesh.Sets a shared Certificate Authority across the defined meshes.|
|federation||networking.mesh.gloo.solo.io.VirtualMeshSpec.Federation||Determine how to expose traffic targets to cross-mesh traffic using Service Federation.|
|globalAccessPolicy||networking.mesh.gloo.solo.io.VirtualMeshSpec.GlobalAccessPolicy||Sets an Access Policy for the whole mesh.|
In Gloo Mesh, “federation” refers to the ability to expose traffic targets with a global DNS name for traffic originating from any workload within the virtual mesh.
|permissive||google.protobuf.Empty||Select permissive mode to expose all traffic targets in a VirtualMesh to cross-cluster traffic from all workloads in that Virtual Mesh.|
|flatNetwork||bool||If true, all multicluster traffic will be routed directly to the service endpoints of the traffic targets, rather than through an ingress gateway. NOTE: This feature will not work if the clusters are not pre-configured to live on the same network.|
|hostnameSuffix||string||Configure the suffix for hostnames of traffic targets federated within this virtual mesh. Currently this is only supported for Istio with smart DNS proxying enabled. If any meshes do not have smart DNS proxying enabled, setting this field results in an error. If omitted, the hostname suffix defaults to “global”.|
Mutual TLS Config for a Virtual Mesh. This includes options for configuring Mutual TLS within an indvidual mesh, as well as enabling mTLS across Meshes by establishing cross-mesh trust.
|shared||networking.mesh.gloo.solo.io.VirtualMeshSpec.MTLSConfig.SharedTrust||Shared trust (allow communication between any workloads and traffic targets in the grouped Meshes).|
|limited||networking.mesh.gloo.solo.io.VirtualMeshSpec.MTLSConfig.LimitedTrust||Limited trust (selectively allow communication between workloads and traffic targets in the grouped Meshes).|
|autoRestartPods||bool||Allow Gloo Mesh to restart mesh pods when certificates are rotated. If this option is not explicitly enabled, users must restart the pods manually for the new certificates to be picked up.
Limited trust is a virtual mesh trust model which does not require all meshes sharing the same root certificate or identity model. But rather, the limited trust creates trust between meshes running on different clusters by connecting their ingress/egress gateways with a common cert/identity. In this model all requests between different have the following request path when communicating between clusters
cluster 1 MTLS shared MTLS cluster 2 MTLS client/workload <———–> egress gateway <———-> ingress gateway <————–> server
This approach has the downside of not maintaining identity from client to server, but allows for ad-hoc addition of additional clusters into a virtual mesh.
Shared trust is a virtual mesh trust model requiring a shared root certificate, as well as shared identity between all entities which wish to communicate within the virtual mesh.
The best current example of this would be the replicated control planes example from Istio: https://preliminary.istio.io/docs/setup/install/multicluster/gateways/
|rootCertificateAuthority||networking.mesh.gloo.solo.io.VirtualMeshSpec.RootCertificateAuthority||Configure a Root Certificate Authority which will be shared by the members of the virtual mesh. If this is not provided, a self-signed certificate will be used by Gloo Mesh to establish shared trust for the purposes of failover and federation.|
RootCertificateAuthority defines parameters for configuring the root CA for a Virtual Mesh.
|generated||networking.mesh.gloo.solo.io.VirtualMeshSpec.RootCertificateAuthority.SelfSignedCert||Generate a self-signed root certificate with the given options.|
|secret||core.skv2.solo.io.ObjectRef||Use a root certificate provided in a Kubernetes Secret. [Secrets provided in this way must follow a specified format, documented here.](|
Configuration for generating a self-signed root certificate. Uses the X.509 format, RFC5280.
|ttlDays||uint32||Number of days before root cert expires. Defaults to 365.|
|rsaKeySizeBytes||uint32||Size in bytes of the root cert's private key. Defaults to 4096.|
|orgName||string||Root cert organization name. Defaults to “gloo-mesh”.|
|observedGeneration||int64||The most recent generation observed in the the VirtualMesh metadata. If the observedGeneration does not match generation, the controller has not received the most recent version of this resource.|
|state||networking.mesh.gloo.solo.io.ApprovalState||The state of the overall resource. It will only show accepted if it has been successfully applied to all target meshes.|
|errors||string||repeated||Any errors found while processing this generation of the resource.|
|meshes||networking.mesh.gloo.solo.io.VirtualMeshStatus.MeshesEntry||repeated||The status of the VirtualMesh for each Mesh to which it has been applied. A VirtualMesh may be Accepted for some Meshes and rejected for others.|
If ENABLED, by default disallow traffic to all Services in the VirtualMesh unless explicitly allowed through AccessControlPolicies. If DISABLED, by default allow traffic to all Services in the VirtualMesh. If MESH_DEFAULT, the default value depends on the type service mesh: Istio: false Appmesh: true