Network traffic
Review your options to secure the network traffic in your cluster.
Ingress traffic
You can protect the workloads in your cluster by securing your gateway for incoming traffic.
Listener configuration
A listener is a process on the gateway that checks for incoming connection requests for a specific domain, IP address, port, and protocol. When a request is received, the gateway verifies the request by using the rules that you defined, and then forwards the request to the destination in the cluster.
Before you set up a listener in your gateway, you must decide how the client connects to the gateway and how the request is forwarded within the cluster after it is being accepted by the gateway. For example, to secure the connection from the client to the gateway, you can configure your listeners to accept only HTTPS or TLS requests. After the request is accepted, you can decide if you want to terminate the TLS connection and forward the unencrypted request to the destination in your cluster, or if you want to pass the encrypted request through to the destination. Note that if you decide to pass a TLS request through, the destination must be capable of terminating the TLS connection.
You also have the option to terminate a TLS connection at the gateway, and originate a new TLS connection from the gateway to the destination by using the client TLS policy. With this approach, your request is encrypted and protected as the it travels from a client to the destination.
To find a list of supported listeners, see Configure gateway listeners. For an overview about your listener configuration options and to find the right listener for your setup, see Listener overview
Deny traffic by default
You can enable the gatewayDefaultDenyAllHTTPRequests feature gate in your Gloo Mesh Gateway installation to automatically deny all requests to your HTTP routes if no ExtAuthPolicy or JwtPolicy is applied to the route.
To deny all requests for a route, you add the gateway.gloo.solo.io/require_auth: "true" to the route that you want to protect. You have the option to protect individual routes, or apply this label to all routes in a route table or delegated route table. Access to the route is granted only if an auth policy is applied to the route, such as an ExtAuthPolicy or JwtPolicy, and the client request can be authenticated successfully.
Without the gateway.gloo.solo.io/require_auth: "true" label, requests to your routes are allowed by default. You can still apply auth policies to protect routes. However, if your auth policies are deleted, misconfigured, or otherwise not persisted in the Envoy proxy, then the route becomes exposed again. By using the gatewayDefaultDenyAllHTTPRequests feature gate, you can safeguard against such accidental exposure.
For more information, see /gloo-gateway/latest/routing/deny-traffic-default/ .
External authentication
Gloo Gateway offers a variety of options to ensure external requests are authenticated and authorized before the request is forwarded to an app in your cluster. For example, you can set up basic, passthrough, API key, OAuth, or OPA authentication. You can also integration with company's LDAP provider to sync user logins with your company's directory. For an overview of external auth options, see External authentication and authorization.
Rate limiting
With rate limiting, you limit the number of incoming traffic requests that can be sent to an API or service over a specific time interval, such as per second, minute, hour, or day. For example, you might say that your website can handle 1,000 requests per second. If this rate is exceeded, such as in the event of a malicious attack, access to your API is denied at the gateway. For more information about how to set up rate limiting, see Rate limit.
Other traffic policies
After a request is accepted by the gateway, you can apply policies to your request to enhance the security of your setup. For example, you can add traffic policies, such as Web Application Firewalls, timeouts, retries, outlier detection, mirroring, header manipulation, or custom Web Assembly filters. To terminate the TLS connection at the gateway, and originate a new TLS connection from the gateway to the destination, you can use the client TLS policy. For a list of supported traffic policies, see Supported policies.
Network traffic in the cluster
When requests successfully enter your cluster, you can leverage the following Gloo features to secure your network traffic.
Internal hostnames
To reduce the surface of vulnerability even more, consider using Gloo virtual destinations to map external hostnames to internal hostnames. Gloo Gateway can use these internal hostnames to forward incoming requests to an app in your cluster. If you have multiple instances of your app that spread across clusters, virtual destinations can also be used to simplify routing between clusters. For more information, see Deployment patterns.
Gloo workspaces
With Gloo workspaces, you can organize Kubernetes and Gloo resources for your teams and determine what resources are visible to each team. Workspaces allow for multitenancy and serve as a boundary for team resources across Kubernetes namespaces and clusters. For more information about workspaces and how to set them up, see Multitenancy with workspaces.
RBAC policies
You can use Kubernetes RBAC policies to grant access to Kubernetes and Gloo resources in your cluster. With RBAC policies, you can control who can manage and change your Kubernetes and Gloo setup. For more information, see User access.
Other Gloo products
You can use other Gloo products to further secure the network traffic in your cluster.
Gloo Mesh Enterprise: With Gloo Mesh, you use a service mesh to secure the communication between apps in your cluster by using mTLS. You can use the same Gloo Gateway policies for securing ingress traffic to secure service-to-service communication in your mesh. For example, when app A wants to send a request to app B, you can set up policies, such as retries, timeouts, outlier detection, and more to secure this connection. In addition, you can set up service isolation so that services cannot communicate with services that do not belong to the service mesh. Additionally, because Gloo Mesh Enterprise includes support for Solo distributions of Cilium, you can deploy the Cilioum CNI to your clusters and use Cilium network policies to allow or drop packages between apps on layer 3 and 4 of the OSI Networking model. Cilium is an open source technology and a highly scalable Kubernetes Container Network Interface (CNI) that provides cloud-native networking connectivity, security, and observability for container-based workloads, such as in Kubernetes and Docker. To provide advanced networking and security controls, Cilium leverages the Linux kernel technology eBPF.
Other tools
Besides the workloads that you deploy to your cluster, your app design, container platform, and underlying infrastructure provider all impact the security posture of your apps. Refer to the following links to learn more about how to further secure the network in your cluster.