About the feature gate

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.

Feature considerations

Before using this feature, keep in mind the following considerations.

  • Response behavior change: When you enable the feature gate, the gateway denies unauthorized requests with a 403 HTTP response code, even if the route is not found which typically returns a 404 HTTP response code. As such, this response behavior change might affect automation that you have in place, such as to monitor or troubleshoot logs.
  • Ingress gateway only: You can use this feature with an Istio ingress gateway for north-south traffic within the service mesh. This feature does not support east-west gateways or egress gateways for traffic that leaves the service mesh.
  • HTTP routes only: You can use this feature to set up the ingress gateway to deny all requests for HTTP/HTTPS routes only. This feature does not support other types of routes, such as TLS or TCP.
  • Gloo external auth service only: You must use the Gloo external auth service to enforce the auth policies to the routes. You cannot use your own custom external auth service. You can add the gateway.gloo.solo.io/require_auth: "false" label to these routes so that you know that the routes are not protected by the gatewayDefaultDenyAllHTTPRequests feature gate.
  • JwtPolicy cannot allow missing or failed JWT: Your JwtPolicies cannot set the allowMissingOrFailed field or the validationPolicy field to ALLOW_MISSING or ALLOW_MISSING_OR_FAILED JWTs. For the deny all feature gate to work, the gateway needs a valid JWT. Because JwtPolicies with those fields might allow a missing or invalid JWT, the gateway denies requests to the route. Instead, consider these options:
    • You can apply an additional ExtAuthPolicy, so that some type of auth is enforced on the route. This way, you can configure ALLOW_MISSING or ALLOW_MISSING_OR_FAILED JWTs because the request can successfully authenticate via external auth.
    • You can disable this feature for the route that you want to allow a missing or failed JWT by applying the gateway.gloo.solo.io/require_auth: "false" label on that route.
  • JWT must have iss claim: For the gatewayDefaultDenyAllHTTPRequests feature gate to work, JWT claims must include an iss claim. If not, the gateway denies the request. Note that this behavior differs from the regular gateway behavior, which can authenticate JWTs that do not to have the iss claim.
  • Version requirements: To enable this feature, you must use a Solo distribution of Istio (not community Istio) version 1.19.5, 1.20.1, or later.

Deny requests to your routes by default

To deny requests to your routes by default, you enable the gatewayDefaultDenyAllHTTPRequests feature gate in your Gloo Mesh Gateway installation. Then, when you set up routing for your app, add the gateway.gloo.solo.io/require_auth: "true" label to the route that you want to deny requests for. Note that Gloo Mesh Gateway only respects this label when the gatewayDefaultDenyAllHTTPRequests feature gate is enabled.

  1. Install or upgrade Gloo Mesh Gateway with the gatewayDefaultDenyAllHTTPRequests feature gate enabled. In multicluster setups, you must enable this feature gate in the management cluster installation. For more information, see the Feature gate and Helm reference docs.

  2. Deploy the httpbin sample app.

  3. Configure a virtual gateway with an HTTP or HTTPS listener. The following example creates a sample HTTP listener for the ingress gateway.

      kubectl apply -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: VirtualGateway
    metadata:
      name: istio-ingressgateway
      namespace: httpbin
    spec:
      listeners:
      - http: {}
        port:
          number: 80
      workloads:
      - selector:
          labels:
            istio: ingressgateway
    EOF
      
  4. Create a route table for the sample httpbin app. Include the gateway.gloo.solo.io/require_auth: "true" label to each route that you want to deny requests to by default. You can apply the label to an entire route table, delegated routes, or individual routes, such as in the following examples.

Good job! Now, routes with the gateway.gloo.solo.io/require_auth: "true" label are protected by default. Any traffic requests sent to these routes are automatically denied with a 403 response. To allow traffic, you must apply an auth policy, such as an ExtAuthPolicy or JwtPolicy. For an example, continue to the next step to verify your setup.

Verify your secured routes

To verify your secured routes, send a series of requests to the routes. For requests to succeed, the routes must have an external auth or JWT policy that is applied to the routes and in an Accepted state. The following example sets up various JWT policies to demonstrate the feature.

  1. Save the external address of the ingress gateway.

  2. Send a request to the httpbin-secure route. The request is denied with a 403 response because the route does not have an attached auth policy.

    Example output:

      HTTP/2 403
      
  3. Send a request to the httpbin-insecure route. The request succeeds with a 200 response even though the route does not have an attached auth policy. The gateway does not deny requests by default because you included the gateway.gloo.solo.io/require_auth: "false" label to allow a more permissive route

    Example output:

      HTTP/2 200
      
  4. Apply a JWT policy to the route. The following example uses sample keys and a dev-example JWT. For more details about the sample JWT, see the GitHub readme.

      kubectl apply -f https://gist.githubusercontent.com/artberger/674bab05350c9a048303cc7daaffe730/raw/daf7d9b64e5e9ecf309f17123e01f5a6cbb6c7eb/jwt-policy-basic.yaml
      
  5. Get a sample JWT that is preconfigured to meet the validation requirements that you set in the JWT policy for the dev-example provider.

      TOKEN=$(curl https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/gloo-gateway/jwt/dev-example.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode
      

    Example output:

      {"iss":"https://dev.example.com","exp":4804324736,"iat":1648651136,"org":"internal","email":"dev1@solo.io","group":"engineering","scope":"is:developer%
      
  6. Repeat the request to the httpbin-secure route, this time with your valid JWT. The request now succeeds with a 200 response because the route has an attached auth JWT policy and you included a valid JWT in your request.

    Example output with a valid JWT:

      HTTP/2 200
      

    Example output with an invalid JWT:

      HTTP/2 401
      
  7. Delete the JWT policy that secures the httpbin-secure route and repeat the request. Notice that the request is denied again because the feature gate denies requests to the route by default. This way, the route stays protected in cases where the policy is accidentally deleted or misconfigured.

      kubectl delete JwtPolicy -n httpbin jwt-policy
      

    Example output:

      HTTP/2 403
      

Cleanup

You can optionally remove the resources that you set up as part of this guide.
  1. Delete the routing and policy resources that you created.

      kubectl delete VirtualGateway -n httpbin istio-ingressgateway
    kubectl delete RouteTable -n httpbin httpbin
    kubectl delete RouteTable -n gloo-mesh-gateways gateway #for delegated example
    kubectl delete JwtPolicy -n httpbin jwt-policy
      
  2. If you do not want to use this feature anymore, you can disable the feature gate. Upgrade Gloo Mesh Gateway and disable the gatewayDefaultDenyAllHTTPRequests feature gate. In multicluster setups, disable this feature gate in the management cluster. For more information, see the Feature gate and Helm reference docs.