Table of Contents
Specify parameters for configuring the root certificate authority for a VirtualMesh.
|generated||certificates.mesh.gloo.solo.io.CommonCertOptions||Generate a self-signed root certificate with the given options.|
|secret||core.skv2.solo.io.ObjectRef||Reference to a Kubernetes Secret containing the root certificate authority. Provided secrets must conform to a specified format, documented here.|
Shared trust is a trust model requiring a common root certificate shared between trusting Meshes, as well as shared identity between all Workloads and Destinations which wish to communicate within the VirtualMesh.
|rootCertificateAuthority||networking.mesh.gloo.solo.io.RootCertificateAuthority||Configure a Root Certificate Authority which will be shared by all Meshes associated with this VirtualMesh. If this is not provided, a self-signed certificate will be generated by Gloo Mesh.|
|intermediateCertificateAuthority||certificates.mesh.gloo.solo.io.IntermediateCertificateAuthority||Configures an Intermediate Certificiate Authority which remote clusters will use to generate intermediate certificates. In order for this to properly mesh all of the traffic across the different meshes, the CA being used must be configured to generate the intermediate certificates.|
|intermediateCertOptions||certificates.mesh.gloo.solo.io.CommonCertOptions||Configuration options for generated intermediate certs.|
Represents a logical grouping of Meshes for shared configuration and cross-mesh interoperability.
|meshes||core.skv2.solo.io.ObjectRef||repeated||Specify the Meshes configured by this VirtualMesh.|
|mtlsConfig||networking.mesh.gloo.solo.io.VirtualMeshSpec.MTLSConfig||Specify mTLS options.|
|federation||networking.mesh.gloo.solo.io.VirtualMeshSpec.Federation||Specify how to federate Destinations across service mesh boundaries.|
|globalAccessPolicy||networking.mesh.gloo.solo.io.VirtualMeshSpec.GlobalAccessPolicy||Specify a global access policy for all Workloads and Destinations associated with this VirtualMesh.|
“Federation” refers to the ability to expose Destinations across service mesh boundaries, i.e. to traffic originating from Workloads external to the Destination's Mesh.
|ingressGatewaySelectors||common.mesh.gloo.solo.io.IngressGatewaySelector||repeated||Selects the Destination(s) acting as ingress gateways for cross cluster traffic. The supplied IngressGatewaySelectors will be used to select ingress gateways for all Meshes in this VirtualMesh.|
|selectors||networking.mesh.gloo.solo.io.VirtualMeshSpec.Federation.FederationSelector||repeated||Selectively federate Destinations to specific external meshes. If omitted, no Destinations will be federated.|
|flatNetwork||bool||If true, all multicluster traffic will be routed directly to the Kubernetes service endpoints of the Destinations, rather than through an ingress gateway. This mode requires a flat network environment. This feature is exclusive to Gloo Mesh Enterprise.|
|hostnameSuffix||string||Configure the suffix for hostnames of Destinations federated within this VirtualMesh. Currently this is only supported for Istio with smart DNS proxying enabled, otherwise setting this field results in an error. If omitted, the hostname suffix defaults to “global”.|
|tcpKeepalive||common.mesh.gloo.solo.io.TCPKeepalive||Specify a keepalive rule for all requests made within the VirtualMesh which cross clusters within that VirtualMesh, as well as any requests to externalService type destinations.|
Selects a set of Destinations to federate to the referenced Meshes.
|destinationSelectors||common.mesh.gloo.solo.io.DestinationSelector||repeated||The set of Destinations that will be federated to external Meshes. If omitted, all Destinations will be selected.|
|meshes||core.skv2.solo.io.ObjectRef||repeated||The Meshes to which the selected Destinations will be federated. All referenced Meshes must exist in this VirtualMesh. If omitted, the selected Destinations will be federated to all Meshes in the VirtualMesh.|
Specify mTLS options. This includes options for configuring Mutual TLS within an individual Mesh, as well as enabling mTLS across Meshes by establishing cross-mesh trust.
|shared||networking.mesh.gloo.solo.io.SharedTrust||Shared trust (allow communication between any pair of Workloads and Destinations in the grouped Meshes).|
|limited||networking.mesh.gloo.solo.io.VirtualMeshSpec.MTLSConfig.LimitedTrust||Limited trust (selectively allow communication between Workloads and Destinations in the grouped Meshes). Currently not available.|
|autoRestartPods||bool||NOTE: THIS IS NOT A RECOMMENDED SETTING FOR PRODUCTION! Specify whether to allow Gloo Mesh to restart Kubernetes Pods when certificates are rotated when establishing shared trust. This will auto-restart ALL of the workloads in your mesh. It is a convenience feature while testing Gloo Mesh. If this option is not explicitly enabled, users must restart Pods manually for the new certificates to be picked up.
|rotationVerificationMethod||certificates.mesh.gloo.solo.io.CertificateRotationVerificationMethod||Type of rotation verification to use when rotating root certificates.|
|rotationStrategy||certificates.mesh.gloo.solo.io.CertificateRotationStrategy||Type of rotation to use.|
Limited trust is a trust model which does not require trusting Meshes to share the same root certificate or identity. Instead, trust is established between different Meshes by connecting their ingress/egress gateways with a common certificate/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 Meshes into a VirtualMesh.
|observedGeneration||int64||The most recent generation observed in the the VirtualMesh metadata. If the
|state||common.mesh.gloo.solo.io.ApprovalState||The state of the overall resource. It will only show accepted if it has been successfully applied to all selected 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.|
|destinations||networking.mesh.gloo.solo.io.VirtualMeshStatus.DestinationsEntry||repeated||The status of the VirtualMesh for each Destination to which it has been applied. A VirtualMesh may be Accepted for some Destinations and rejected for others.|
|conditions||certificates.mesh.gloo.solo.io.CertificateRotationCondition||repeated||List of rotation conditions which have been completed/carried out for this Virtual Mesh|
|deployedSharedTrust||networking.mesh.gloo.solo.io.SharedTrust||A copy of the shared_trust object currently deployed in the cluster. If the shared trust object in the spec is different from this, we need to start a new rotation.|
Specify a global access policy for all Workloads and Destinations associated with this VirtualMesh.
|MESH_DEFAULT||0||Assume the default for the service mesh type. Istio defaults to
|ENABLED||1||Disallow traffic to all Destinations in the VirtualMesh unless explicitly allowed through AccessPolicies.|
|DISABLED||2||Allow traffic to all Destinations in the VirtualMesh unless explicitly disallowed through AccessPolicies.|