☰
Navigation :

Apply policies

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:

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

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.

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:

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.

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>". Note: If you have a use case for applying multiple policies of the same type that is limited by this behavior, contact your account representative to request more specific merge capabilities.

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.

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.
  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 in the Gloo Gateway docs.
    • 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: