Benefits
Review the benefits that Gloo Network provides as a standalone container network interface (CNI) and when used in a service mesh that is managed by Gloo Mesh Enterprise.
Standalone CNI
| Benefit | Description |
|---|---|
| Control traffic with policies | With Gloo Network, you get advanced app security without modifying the app code or the configuration of your containers. When you apply Gloo Network policies, Gloo automatically translates these policies into Layer 3, 4, or 7 policies to control network traffic in the cluster before traffic reaches your workload. You can also leverage container, pod, and service metadata in addition to protocols, such as HTTP, TCP, or UDP to create identity and application-aware networking rules. To protect your services even further, you can set up Gloo workspaces, enable service isolation, or use Gloo Network with a service mesh that is managed by Gloo Mesh Enterprise. |
| Multitenancy and zero trust with workspaces | With Gloo workspaces, you can define the boundary of Kubernetes resources that your team has access to. These resources can be spread across namespaces or clusters. Gloo Network policies are automatically translated and applied within the workspace's boundaries. You can optionally turn on service isolation to prevent services from one workspace to be able to communicate with services in a different workspace. |
| Enhanced performance | Instead of using iptables rules to route traffic in a cluster, Gloo Network uses the kernel technology eBPF to shorten the data path of a packet. With eBPF, packets to and from apps can be directly forwarded and written to the socket of the target app. This setup reduces network latency and the necessary packet processing in the kernel as the TCP/IP stack in the OSI network model is bypassed. In addition, you decrease CPU and memory overhead on your cluster worker nodes, and can use the freed up resources to manage cluster workloads more efficiently. |
| N-4 version support for Cilium | Gloo Network includes n-4 Cilium version support with security patches to address Common Vulnerabilities and Exposures (CVEs) starting with the first Gloo Network release. |
| Built-in observability tools | Gloo Network is fully built in to the Gloo Platform stack which provides out-of-the-box observability tools, such as the Gloo UI and Prometheus. You can use these tools to gain visibility into the communication and behavior of services, monitor network traffic, and debug network policies. |
| Central Gloo management | Leverage the Gloo management plane to automatically translate Gloo network policies into Cilium network policies, and to deploy and configure the Cilium agent across clusters. |
Gloo Mesh-managed service mesh
Although Cilium has support for Layer 7 policies, these policies require starting an Envoy proxy process in the Cilium agent to enforce the policy. The Envoy proxy intercepts the traffic to and from each pod, which is similar to how Gloo Mesh Enterprise intercepts traffic by using Envoy sidecars (Istio sidecar architecture) or ztunnels (Istio sidecarless architecture).
However, Cilium Layer 7 capabilities are limited in terms of establishing service identity, supporting policies, encrypting data, and providing multitenancy. For more information, check out this blog.
To overcome these limitations, you can use Gloo Network in combination with a service mesh that is managed by Gloo Mesh Enterprise. With this approach, you get advanced security controls, connectivity, and observability through Layer 3-7 of the OSI networking model while optimizing the performance in your service mesh with eBPF.
Review the following table for an overview of benefits when using Gloo Network and Gloo Mesh Enterprise. Note that you get these benefits in addition to the benefits that a standalone Gloo Network installation provides.
| Benefit | Description |
|---|---|
| Defense-in-depth | When using Gloo Network with a service mesh that is managed by Gloo Mesh Enterprise, you can create a multi-layer defense mechanism that protects your apps from being compromised. Gloo Mesh offers a variety of Layer 7 traffic policies that you can apply to your service mesh in addition to the Layer 3/4 network policies that Gloo Network offers to increase the security posture of your apps. For example, you can create L7 policies such as external auth, rate limiting, fault injection, outlier detection, retries, timeouts, mirroring, transformation, WAF, Wasm, and more. By combining both worlds, you can address many different attack vectors. If one layer is compromised, your apps are still protected by policies that are enforced on other layers. For more information about supported policies in Gloo Mesh, see Control traffic with policies. |
| Pod identity | Gloo Mesh uses X.509 certificates to establish pod identity. Pods must present a valid Kubernetes service account token to the Istio control plane that is managed by Gloo Mesh in order to receive the certificate. Certificates are automatically rotated and renewed every 12 hours. |
| Mutual TLS (mTLS) | Gloo Mesh uses Istio's mutual TLS capabilities to automatically encrypt traffic between pods and provide pod authentication. You can optionally use Gloo Mesh's external auth policies to apply request authentication and integrate with your preferred identity provider. |
| Request authorization | To further secure your service mesh, use Gloo Mesh's access and external auth policies to specify what services in the mesh can talk to each other. |
| Multitenancy and zero trust with Gloo workspaces | Gloo Network and Gloo Mesh fully integrate into the Gloo Platform stack which provides Gloo workspaces to enable multitenancy support in your cluster. With workspaces, you can define the boundary of Kubernetes resources that your team has access to. These resources can be spread across namespaces or clusters. Gloo Network and Gloo Mesh policies are automatically translated and applied within the workspace's boundaries. |
| eBPF sidecar acceleration | When using Gloo Mesh and Gloo Network, you can shorten the pod-to-pod data path by using eBPF. Instead of using iptables rules to redirect ingress and egress traffic from an app container to the injected Istio sidecar proxy and vice versa, eBPF is used to intercept the traffic and shorten the data path in a service mesh. With eBPF, packets to and from apps can be directly forwarded from one socket to the other. This setup reduces network latency and the necessary packet processing in the kernel. |
| Multicluster mesh and multicluster routing | With Gloo Mesh Enterprise and central Gloo Platform management, you can onboard workloads in multiple clusters to your service mesh, and use Gloo custom resources, such as traffic or network policies to secure network traffic between clusters. |
For more information about Gloo Mesh Enterprise, see About Gloo Mesh. To learn more about Gloo Platform capabilities, see Gloo Platform overview.