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 Gateway listeners. For an overview about your listener configuration options and to find the right listener for your setup, see the 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 Deny requests to routes.

External authentication

Gloo Mesh 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 Mesh 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 products

You can use Gloo Mesh Enterprise to further secure the network traffic in your cluster.

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 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.

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.