On this page
Policy overview
Learn more about the custom resources that you can use to apply policies in Gloo Gateway.
While the Kubernetes Gateway API allows you to do simple routing, such as to match, redirect, or rewrite requests, you might want additional capabilities in your API gateway, such as fault injection, data loss prevention, or header control. Policies allow you to apply intelligent traffic management, resiliency, and security standards to individual routes or all the routes that the gateway serves.
Policy CRDs
Gloo Gateway uses the following custom resources to attach policies to routes and gateway listeners:
- DirectResponse: Directly respond to incoming requests with a custom HTTP response code and body.
- ListenerOption: Attach policies to one, multiple, or all gateway listeners.
- HTTPListenerOption: Apply policies to one, multiple, or all HTTP and HTTPS listeners.
- RouteOption: Attach policies to one, multiple, or all routes in an HTTPRoute resource.
- VirtualHostOption: Attach policies to the hosts on one, multiple, or all gateway listeners.
Supported policies
Review the policies that you can configure in Gloo Gateway and the level at which you can apply them.
Traffic management policies
| Policy | Applied via | Precedence and merging rules | Enterprise license required? |
|---|---|---|---|
| Connection buffer limits | ListenerOption | No cross-resource conflict. Policies can conflict only if applied in multiple ListenerOption resources. For more information, see Conflicting policies. | No |
| Direct response | DirectResponse | Supported in version 1.18 and later. No cross-resource conflict. If multiple DirectResponse resources are applied to the same route, only the one that is referenced first is enforced. | No |
| External processing |
| RouteOption configuration takes precedence over VirtualHostOption configuration, which takes precedence over HttpListenerOption configuration. Policies that are defined at different levels are not merged. | Yes |
| Fault injection | RouteOption | No cross-resource conflict. Policies can conflict only if applied in multiple RouteOption resources. For more information, see Conflicting policies. | No |
| Gateway health checks | HttpListenerOption | No cross-resource conflict. Policies can conflict only if applied in multiple HttpListenerOption resources. For more information, see Conflicting policies. | Yes |
| Header control |
| Headers that are defined at the route and virtual host-level are merged as long as they do not conflict. If the same header is defined in both a RouteOption and VirtualHostOption resource, the RouteOption configuration takes precedence and the VirtualHostOption configuration is ignored. | No |
| Proxy protocol | ListenerOption | No cross-resource conflict. Policies can conflict only if applied in multiple ListenerOption resources. For more information, see Conflicting policies. | No |
| Rewrites | RouteOption | No cross-resource conflict. Policies can conflict only if applied in multiple RouteOption resources. For more information, see Conflicting policies. | No |
| Transformations |
| RouteOption configuration takes precedence over VirtualHostOption configuration. Policies that are defined at different levels are not merged. | No |
Resiliency policies
| Policy | Applied to | Precedence and merging rules | Enterprise license required? |
|---|---|---|---|
| Caching | HttpListenerOption | No cross-resource conflict. Policies can conflict only if applied in multiple HttpListenerOption resources. For more information, see Conflicting policies. | Yes |
| Fault injection | RouteOption | No cross-resource conflict. Policies can conflict only if applied in multiple RouteOption resources. For more information, see Conflicting policies. | No |
| Retries |
| RouteOption configuration takes precedence over VirtualHostOption configuration. Policies that are defined at different levels are not merged. | No |
| Shadowing | RouteOption | No cross-resource conflict. Policies can conflict only if applied in multiple RouteOption resources. For more information, see Conflicting policies. | No |
| Tapping | HttpListenerOption | No cross-resource conflict. Policies can conflict only if applied in multiple HttpListenerOption resources. For more information, see Conflicting policies. | Yes |
| Timeouts | RouteOption | No cross-resource conflict. Policies can conflict only if applied in multiple RouteOption resources. For more information, see Conflicting policies. | No |
Security policies
| Policy | Applied to | Precedence and merging rules | Enterprise license required? |
|---|---|---|---|
| Access logging | ListenerOption | No cross-resource conflict. Policies can conflict only if applied in multiple ListenerOption resources. For more information, see Conflicting policies. | No |
| CORS |
| By default, the configuration of the RouteOption takes precedence over the VirtualHostOption. However, you can change this behavior for the exposeHeaders CORS option by using the corsPolicyMergeSettings field in the VirtualHostOption. Currently, only exposeHeaders is configurable. You cannot merge other CORS options such as allowHeaders or allowOrigin. For more information about this option, see the CORS configuration options. | No |
| CSRF |
| RouteOption configuration takes precedence over VirtualHostOption configuration, which takes precedence over HttpListenerOption configuration. Policies that are defined at different levels are not merged. | No |
| Data loss prevention |
| RouteOption configuration takes precedence over VirtualHostOption configuration, which takes precedence over HttpListenerOption configuration. Policies that are defined at different levels are not merged. | Yes |
| External authentication and authorization |
| RouteOption configuration takes precedence over VirtualHostOption configuration, which takes precedence over HttpListenerOption configuration. Policies that are defined at different levels are not merged. | Yes |
| Local rate limiting | HttpListenerOption | No cross-resource conflict. Policies can conflict only if applied in multiple HttpListenerOption resources. For more information, see Conflicting policies. | No |
| Global rate limiting |
| RouteOption configuration takes precedence over VirtualHostOption configuration. Policies that are defined at different levels are not merged. | Yes |
| JWT |
| RouteOption configuration takes precedence over VirtualHostOption configuration. Policies that are defined at different levels are not merged. | Yes |
| Web Application Firewall (WAF) |
| RouteOption configuration takes precedence over VirtualHostOption configuration, which takes precedence over HttpListenerOption configuration. Policies that are defined at different levels are not merged. | Yes |
Policy inheritance rules when using route delegation
Policies that are defined in a RouteOption resource and that are applied to a parent HTTPRoute resource are inherited by all the child or grandchild HTTPRoutes along the route delegation chain. The following rules apply:
- Only policies that are specified in a RouteOption resource can be inherited by a child HTTPRoute. For inheritance to take effect, you must use the
spec.targetRefsfield in the RouteOption resource to apply the RouteOption resource to the parent HTTPRoute resource. Any child or grandchild HTTPRoute that the parent delegates traffic to inherits these policies. - You can add the
delegation.gateway.solo.io/enable-policy-overridesannotation to a parent HTTPRoute to allow its immediate child HTTPRoutes to override the top-level policies that are defined on the parent. You have the option to allow overriding policies of all types (delegation.gateway.solo.io/enable-policy-overrides: "*") or to limit the type of policies that a child can override (delegation.gateway.solo.io/enable-policy-overrides: "faults,headerManipulation,cors"). - In a multi-level delegation chain with parent, child, and grandchild HTTPRoutes, the parent and the child HTTPRoutes must both set the
delegation.gateway.solo.io/enable-policy-overridesannotation for the grandchild to be able to override the top-level policies that were defined on the parent. - If no
delegation.gateway.solo.io/enable-policy-overridesannotation is set on the parent and the child HTTPRoute sets a policy that is already defined on the parent HTTPRoute, the setting on the parent HTTPRoute takes precedence and the setting on the child is ignored. For example, if the parent HTTPRoute defines a data loss prevention policy, the child HTTPRoute cannot change these settings or disable that policy. - If no
delegation.gateway.solo.io/enable-policy-overridesannotation is set on the parent HTTPRoute, child HTTPRoutes can augment the inherited settings by defining RouteOption fields that were not already set on the parent HTTPRoute.
For an example, see the Policy inheritance guide.