Review your options to secure the network traffic in your cluster.
You can protect the workloads in your cluster by securing your gateway for incoming traffic.
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
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.
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.
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.
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.
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. To learn more about Gloo Mesh Enterprise, see About Gloo Mesh.
- Gloo Network: 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. For more information about Gloo Network, see About Gloo Network.
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.