With Gloo policies, you can manipulate and control network traffic to the apps in your cluster. Policy behavior depends on several factors that you set up when creating the policy, including the following:

Apply policies to resources

Policies might apply to the following resources:

  • Destinations: Destinations determine where incoming requests are routed to. A destination can be a Kubernetes Service, a Gloo VirtualDestination in a multicluster setup, or a Gloo ExternalService custom resource that you use to reach endpoints that are outside your service mesh.
  • Listeners: Listeners are the virtual gateways and ports that a gateway workload listens for incoming traffic on. You must apply a listener policy to a Gloo VirtualGateway custom resource, not the gateway workload directly.
  • Route: Routes define how to match an incoming request, and what actions you want to perform on a matched request. For example, you can decide to forward the request to a destination in the service mesh, directly respond to the request without forwarding, or manipulate and redirect requests. Routes are defined in a Gloo RouteTable custom resource.
  • Workloads: A workload represents the app that responds to incoming request. For example, you can have Kubernetes workloads such as Deployments or StatefulSets. Or, you can use an Istio WorkloadEntry that might run in a bare metal or virtual machine outside your Kubernetes cluster.

You can apply the policies by using Kubernetes labels and selectors that match the route table, virtual destination, or workload. Remember, all of these resources must be in the same workspace for the policy to apply the resource. To see what resources a policy might select, check the Kubernetes labels such as with the following commands.

  kubectl get <KIND> <RESOURCE> -n <NAMESPACE> -l <KEY=VALUE>
kubectl get all -A -l env=prod

Some policies support selecting multiple kinds of resources, such as both destinations and routes. When you have multiple selectors, you might wonder how the selectors impact each other. For more information, refer to each policy guide:

Applying multiple policies of the same type to one resource

When you apply multiple policies of the same type to one resource, the results vary based on the type of policy.

Multiple policies supported: For some policies, specific merge capabilities are supported. For example, you can apply multiple additive AccessPolicy resources to the same destination in order to build an allowlist for that particular resource. The following policies support multiple applications of the same type to a single resource:

  • AccessLogPolicy (Gloo Mesh Enterprise only): Configure different log filters for the same workload.
  • AccessPolicy (Gloo Mesh Enterprise only): Build an allowlist for the same resource.
  • ActiveHealthCheckPolicy: Configure multiple health checks on the same destination.
  • DlpPolicy: Mask different kinds of data in responses from the same route.
  • FailoverPolicy (Gloo Mesh Enterprise only): Specify multiple locations to reroute traffic to. See the failover policy guide for more information.
  • TrimProxyConfigPolicy (Gloo Mesh Enterprise only): Specify multiple destinations for one workload to include in the proxy config.
  • WafPolicy: Apply multiple rulesets to protect a route from different kinds of HTTP traffic.

Transformation policies support one per stage: When you attempt to apply multiple transformation policies, all policies are first sorted ascending by creation time, and then grouped by stage (preAuthz and postAuthz). For each stage, only the oldest policy is applied. All subsequent policies are ignored. Note that this behavior applies even if you specify the prioritizedPhase field in your transformation policy.

Other policies do not support multiple: For all other supported Gloo policies for HTTP traffic, when you attempt to apply multiple of the same policy to one resource, only the earliest-created policy is applied. For example, if you applied two RetryTimeoutPolicy resources to the same route, the policy with the earliest creation timestamp is applied, but the policy with the later creation timestamp is ignored. When you apply the second policy, you might see a warning message such as the following: RetryTimeoutPolicy conflicts existing policy applied to route. Skipping applying <later_policy_name>.<namespace>".

Order of applied policies

When you apply a policy, Gloo translates the policy into a filter configuration that is applied in the Envoy proxy. The Envoy proxy might be the ingress gateway or a workload’s sidecar proxy, depending on the Gloo Platform products that you use, and which policy and resource you apply the policy to. For more information, see the Envoy docs about how the HTTP filter and network filter chains process requests, including the reverse order of responses.

Most of Gloo’s supported policies are for HTTP traffic. These policies configure filters within the Envoy proxy’s HTTP Connection Manager. The filters are applied in the order that is shown in the following figure. For example, if you apply both CORS and DLP security filters, a request is processed for CORS first, and then DLP.

For most policies, you cannot change the order. However, for policies that support phases for pre- and post-external auth, you can change the order by setting priorities. For more information, see the Phase API docs.

To verify which filters are applied in which order, see the Policies debug guide.

Figure: Filter order of applied Gloo policies for HTTP traffic.
Figure: Filter order of applied Gloo policies for HTTP traffic.
Figure: Filter order of applied Gloo policies for HTTP traffic.
Figure: Filter order of applied Gloo policies for HTTP traffic.

  1. External auth: When you enable external authorization and authentication, you can secure access to your apps with authentication tools like OIDC, API keys, OAuth2, or OPA. External auth is used to organize the flow in this diagram so that you can quickly see how traffic can be manipulated before or after requiring the client to log in. For more information, see External authentication and authorization.
  2. Before or after external auth: You can configure several traffic filters either before, after, or both before and after a client request is authorized.
    • JWT: You can verify a JSON web token (JWT) signature, check the claims, and add them to new headers. To set JWT before and/or after external auth, use the phase and stage settings. For more information, see JWT.
    • Transformation: Apply transformation templates to the header or body of a request or response. If the body is a JSON payload, you can also extract values from it. To set transformations before or after external auth, use the phase setting. For more information, see Transformation.
    • Rate limiting: Rate limiting can take place before or after external auth. You can use the SetStyle API to build complex rules for rate limiting. For more information, see Rate limit.
  3. Filters only before external auth: Review the information about other filters that you can apply only before external auth.
  4. Filters only after external auth: Review the information about other filters that you can apply only after external auth.
  5. Router: Within the HTTP Connection Manager, the last filter applied is the router. The router forwards the requests to the upstream service, applying any final policy configurations, including the following: