Deny all HTTP requests
For a more secure setup, you can enable a feature gate to deny requests to your HTTP routes by default.
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 thegatewayDefaultDenyAllHTTPRequests
feature gate. - JwtPolicy cannot allow missing or failed JWT: Your JwtPolicies cannot set the
allowMissingOrFailed
field or thevalidationPolicy
field toALLOW_MISSING
orALLOW_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
orALLOW_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.
- You can apply an additional ExtAuthPolicy, so that some type of auth is enforced on the route. This way, you can configure
- JWT must have
iss
claim: For thegatewayDefaultDenyAllHTTPRequests
feature gate to work, JWT claims must include aniss
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 theiss
claim. - Version requirements: To enable this feature, you must use a Solo distribution of Istio (not community Istio) version 1.18.6 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.
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.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
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.
Save the external address of the ingress gateway.
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
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 thegateway.gloo.solo.io/require_auth: "false"
label to allow a more permissive routeExample output:
HTTP/2 200
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
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%
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
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.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
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.