This doc set is for users of the Gloo Mesh Gateway product to set up an Istio ingress gateway. For users of the Gloo Gateway product to set up an ingress gateway with the Kubernetes Gateway API instead, see the Gloo Gateway docs.
Supported policies in Gloo Mesh Gateway
Find an overview of supported policies in Gloo Mesh Gateway and why you want to use them.
Gloo Mesh Gateway supports a variety of policies to ensure network resiliency, traffic control, security, and observability for the microservices in your cluster. Flip through the cards to learn about what policies are supported, why you want to use them, and what Gloo Mesh Gateway resource the policy can be applied to. To see an example policy setup, simply follow the links.
Name | Type | Description | Applied to | Solo distribution of Istio required? |
---|---|---|---|---|
Fault injection | Client-side | Test the resilience of your apps by injecting delays and connection failures. With fault injections, you intentionally introduce errors, such as a failure of an upstream dependency to see how your app behaves and if it can recover from such an event. | Route | No |
Outlier detection | Client-side | Configure Gloo to remove unhealthy destinations from the connection pool, and add the destinations back when they become healthy again. An outlier can be any upstream app instance that is performing differently than other instances that back the Kubernetes service, Gloo Mesh virtual destination, or external service. For example, if an app instance responds with a 5xx HTTP error code most of the time, it is excluded from the Gloo Mesh load balancing. | Destination | No |
Retry | Client-side | Use retry settings to specify the maximum number of times a gateway proxy can attempt to call a service in the mesh after the initial call failed. | Route | No |
Timeout | Client-side | With timeouts, you can specify how long the gateway proxy waits for a service or host to respond before it is considered unavailable. | Route | No |
TCP connection | Client-side | Set up connection pool settings for a TCP destination, such as TCP keepalive. | Destination | No |
Name | Type | Description | Applied to | Solo distribution of Istio required? |
---|---|---|---|---|
Active healthcheck | Client-side | Use the ingress gateway to periodically check the health of an upstream service in your cluster. | Destination | No |
Header manipulation | Client-side | Append or remove HTTP request and response headers at the route level. | Route | No |
HTTP buffer filter | Client-side | Set the maximum request body size that you want to accept for a particular workload in your cluster. | Route | No |
Listener connection | Client-side | Configure connection settings between downstream services and a gateway listener. | Listener | No |
Load balancer and consistent hash | Client-side | Specify how you want Istio to select an upstream service to serve an incoming client request. | Destination | No |
Mirroring | Client-side | Duplicate outgoing traffic, to test a new app. Mirroring, also referred to as shadowing, can be very useful if you want to send live traffic to a different version of your app to verify the app’s behavior or set up canary testing. | Route | No |
Proxy protocol | Client-side | Preserve connection information such as the client IP address for traffic that goes through your gateway listener. | Listener | No |
Rate limiting | Client-side | Control the rate of requests to destinations within the service mesh. With rate limits, you can specify how many requests you want to allow to be passed to a particular service in a certain timeframe. For example, you might want to limit your service to receive only one request per second. | Route or destination | Yes |
Transformation | Client-side | Alter a request before matching and routing, such as with an Inja header template. For example, you might want to add or remove certain headers from the request or response that is routed in your cluster. | Route | Yes |
Name | Type | Description | Applied to | Solo distribution of Istio required? |
---|---|---|---|---|
CORS | Client-side | Enforce client-site access controls with cross-origin resource sharing (CORS). CORS is a browser mechanism that allows a client web app to access resources that are located outside of a specific domain. | Route | No |
CSRF | Client-side | Apply a CSRF filter to the gateway to help prevent cross-site request forgery attacks. A cross-site request forgery attack is a web security vulnerability where the attacker induces an authenticated user to perform an unwanted action on a trusted site. | Route | No |
DLP | Client-side | Ensure that sensitive data isn’t logged or leaked with Data Loss Prevention (DLP). | Route | Yes |
External authentication and authorization | Client-side | Set up an external authentication and authorization to protect the workloads in your cluster. For example, you can set up basic, passthrough, API key, OAuth, OPA, or LDAP authentication. | Route or destination | Yes |
JWT | Client-side | Control access or route traffic based on verified claims in a JSON web token (JWT). Note: You only need a Gloo Mesh Gateway license to apply JWT policies to ingress routes. For internal mesh traffic, you can apply JWTs to destinations or east-west routes with only a Gloo Mesh Enterprise license. | Route | Yes |
WAF | Client-side | Filter, monitor, and block potentially harmful HTTP traffic with a Web Application Firewall (WAF) policy. | Route | Yes |
Name | Type | Description | Applied to |
---|---|---|---|
Certificate Authority options | Client-side | Create a policy for custom CA certificates. | |
Client TLS | Client-side | Enable TLS origination for your ingress gateway so that you can encrypt requests before they are forwarded to HTTPS services in your cluster. | Destination |
Vault | Client-side | Create a policy for Vault-managed certificates. |
You can use the following policies to log or control traffic to service mesh workloads in east-west scenarios.
To use this feature, you must have a Gloo Mesh Enterprise license in addition to your Gloo Mesh Gateway license.
Name | Type | Description | Applied to | Solo distribution of Istio required? |
---|---|---|---|---|
Access policies | Server-side | Control access for workloads in your service mesh. | Workload or destination | No |
Adaptive request concurrency | Client-side | Dynamically adjust the maximum number of concurrent requests that can be sent to a destination. | Destination | Yes |
Failover | Client-side | Use a failover policy to determine where to reroute traffic in case of failure. For example, you can set up a failover policy to route traffic from one availability zone or region to another if that zone or region becomes unavailable. | Destination | No |
Trim proxy config | Client-side | Trim the number of destinations in the Istio sidecar proxy configuration for your workloads to avoid memory pressure issues. | Workload | No |