You can create a JWT policy that applies to specific routes with the RouteOption resource.

About

Review how the RouteOption and VirtualHostOption configurations interact with each other in the following table.

The scenarios correspond with the steps in this guide. Each builds upon the last, updating the resources to test different scenarios. For example, you might update the stage of a JWT policy in a VirtualHostOption, or create a RouteOption with a JWT policy for a different issuer and JWKS provider.

ScenarioRouteOptionVirtualHostOptionBehavior
1 - Protect all routes on the gatewayNo JWT policyJWT policyAll routes on the gateway require a JWT from the provider in the VirtualHostOption.
2 - Protect a specific routeJWT policyNo JWT policyOnly the routes that are configured by the RouteOption require a JWT.
3 - Revise same stage conflictsJWT policy same stageJWT policy same stageFor routes configured by the RouteOption, the RouteOption configuration overrides the VirtualHostOption configuration. These routes require only the JWT that meets the RouteOption JWT policy. JWTs that meet the VirtualHostOption do not work on these routes. Other routes on the gateway still require a JWT that meets the VirtualHostOption JWT policy. You cannot use a JWT with the provider from the RouteOption for the other routes on the gateway.
4 - Set up separate stagesJWT policy different stageJWT policy different stageThe routes that are configured by the RouteOption require two JWTs: one from the provider in the RouteOption, and one from the provider in the VirtualHostOption. Make sure to configure the token source to come from different headers so that requests can pass in both tokens. Note that if you also configure RBAC policies on both options, the RouteOption RBAC policy takes precedence because only one RBAC policy is supported per route.
5 - Add validation policyJWT policy different stageJWT policy different stage with validation policyDepending on the validation policy, the routes that are configured by the RouteOption require at least one JWT. When the validationPolicy field is set to ALLOW_MISSING or ALLOW_MISSING_OR_FAILED, the JWT can be for the provider that is configured in either the RouteOption or the VirtualHostOption. Note that if you set a permissive validation policy on both options, the route does not require any JWT authentication. Make sure to set up the validation policy according to your security requirements.
6 - Delegated routesDifferent JWT policies select delegated routesN/AFor delegated routes, the JWT policies in the parent RouteOption override the child RouteOption when they differ. The same configuration interactions between the route-level RouteOption and the gateway-level VirtualHostOption apply, as described in the previous scenarios.

1: All routes on gateway

Protect multiple routes that are configured on the gateway.

  1. Complete the JWT policy at the gateway level guide. As part of this guide, you set up the following:

    • If you haven’t already, install Gloo Gateway, a Gateway resource, and the httpbin sample app.
    • Create a local JWKS and two sample tokens for Alice and Bob.
    • Apply a JWT policy for all routes on the gateway with a VirtualHostOption.
    • Set up claims-based RBAC with a RouteOption.

  2. Update the HTTPRoute for the httpbin app to create two routes, /get and /status/200.

      kubectl apply -f- <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin
  namespace: httpbin
  labels:
    example: httpbin-route
spec:
  parentRefs:
    - name: http
      namespace: gloo-system
  hostnames:
    - "www.example.com"
  rules:
    - backendRefs:
        - name: httpbin
          port: 8000
      matches:
      - path:
          type: PathPrefix
          value: /status/200
    - backendRefs:
        - name: httpbin
          port: 8000
      matches:
      - path:
          type: PathPrefix
          value: /get
EOF

  3. Send unauthenticated requests to both routes to verify that the JWT policy in the VirtualHostOption applies to all routes on the gateway.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/get -H "host: www.example.com:8080"
curl -vik http://$INGRESS_GW_ADDRESS:8080/status/200 -H "host: www.example.com:8080"
  
      curl -vik localhost:8080/get -H "host: www.example.com:8080"
curl -vik localhost:8080/status/200 -H "host: www.example.com:8080"

    Example output:

      HTTP/1.1 401 Unauthorized
www-authenticate: Bearer realm="http://www.example.com:8080/get"
Jwt is missing
...
HTTP/1.1 401 Unauthorized
www-authenticate: Bearer realm="http://www.example.com:8080/status/200"
Jwt is missing
...

2: Specific routes

Use a RouteOption to protect a specific route with a JWT policy.

  1. Update the RouteOption from the previous scenario as follows.

    • Configure the JWT policy by using the jwtProvidersStaged option, instead of the jwt option. The jwt option does not support configuring a route-level JWT policy.
    • Set up a different provider than what is used in the VirtualHostOption.
    • Remove the target reference to the HTTPRoute, which you update in the next step.
    • To simplify for testing purposes, also remove the RBAC policy (although route-level JWT policies also support setting RBAC policies at the same time).
      kubectl apply -f- <<EOF
apiVersion: gateway.solo.io/v1
kind: RouteOption
metadata:
  name: jwt
  namespace: httpbin
spec:
  options:
    jwtProvidersStaged:
      afterExtAuth:
        providers:
          selfminted:
            issuer: solo.io
            jwks:
              local:
                key: |
                  -----BEGIN PUBLIC KEY-----
                  MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp/ZO8Qhfj6kB5BxndHds
                  x12rgJ2DyU0lvlbC4Ip1zTlULV/Fuy1uAqKbBRC9IyoFiYxuWTLbvpLv5SLnrIPy
                  f4nvX4oHGdyFrcwvCtKvcgtttB363HWiG0PZwSwEn0yMa7s4Rhmy9/ZSYm+sMZQw
                  8wKv40pYnBuqRv1DpfvZLOXvICCkd5f03zv1HQXIfO3YjXOy58vOkajpzTmx4q2A
                  UilrCJcR6tBMoAph5FiJxgRmdLziKx3QXukUSNWfrFVSL+D/BoQV+2TJDZjKfPgj
                  DDMKeb2OsonQ0me3VSw2gkdnE9cyIklXcne/+oKEqineG8a12JSfEibf29iLiIXO
                  gQIDAQAB
                  -----END PUBLIC KEY-----
EOF

  2. Update the HTTPRoute to apply the RouteOption to only the /get route by using an ExtensionRef filter.

      kubectl apply -f- <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin
  namespace: httpbin
  labels:
    example: httpbin-route
spec:
  parentRefs:
    - name: http
      namespace: gloo-system
  hostnames:
    - "www.example.com"
  rules:
    - backendRefs:
        - name: httpbin
          port: 8000
      matches:
      - path:
          type: PathPrefix
          value: /status/200
    - backendRefs:
        - name: httpbin
          port: 8000
      matches:
      - path:
          type: PathPrefix
          value: /get
      filters:
        - type: ExtensionRef
          extensionRef:
            group: gateway.solo.io
            kind: RouteOption
            name: jwt
EOF

  3. Send a request to the /status/200 route with a JWT for the provider in the VirtualHostOption, such as Bob. The request succeeds because the JWT policy from the VirtualHostOption still applies.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/status/200 \
-H "host: www.example.com:8080" \
--header "Authorization: Bearer $BOB_TOKEN"
  
      curl -vik localhost:8080/status/200 \
-H "host: www.example.com:8080" \
--header "Authorization: Bearer $BOB_TOKEN"

    Example output:

      < HTTP/1.1 200 OK
...

  4. Repeat the previous request to the /get endpoint. Now, the request fails because you need a JWT from the provider in the RouteOption.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/get \
-H "host: www.example.com:8080" \
--header "Authorization: Bearer $BOB_TOKEN"
  
      curl -vik localhost:8080/get \
-H "host: www.example.com:8080" \
--header "Authorization: Bearer $BOB_TOKEN"

    Example output:

      < HTTP/1.1 401 Unauthorized
...
Jwt verification fails

  5. Create an environment variable to save a JWT token for the user Carol. Carol’s JWT comes from the provider in the RouteOption. Optionally, you can review the token information by debugging the token in jwt.io.

      export CAROL_TOKEN=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyAiaXNzIjogInNvbG8uaW8iLCAib3JnIjogInNvbG8uaW8iLCAic3ViIjogImNhcm9sIiwgInRlYW0iOiAiZmluYW5jZSIsICJsbG1zIjogeyAib3BlbmFpIjogWyAiZ3B0LTRvIiBdIH0gfQ.UdcOin9UrFdw_42eoypGsAi2eYE4Cr_oe0GYUPD6MePwr6TnWnny3cEQHFFRA9KdntjWBSPtZGKqNlOqg5Juf2-lt7NBLC3ly4esNEKrx_Ul5iKPxelKjNKzdOLdjITOa9FoZ9hZEn2lsn4MG-iftTXPeVn66-nWZryY0BE0Gt2fL1xvZe4Otbj598IY6Z5iPSxQ_fGNRe6f8boW31ePUgTiOthHs7OQv25-eiL8dl1BPBFYywFVGdiiSWrgd_hwRblMegJRhAiOZHRig1sK-NTKRKJpbLhukspM-CZaT1PJgjiOQb_1seeW7mvwUTlqDQA5FZKBCbhihb0TPfo6cw

  6. Repeat the previous request to the /get endpoint, this time with Carol’s token. Now, the request succeeds.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/get \
-H "host: www.example.com:8080" \
--header "Authorization: Bearer $CAROL_TOKEN"
  
      curl -vik localhost:8080/get \
-H "host: www.example.com:8080" \
--header "Authorization: Bearer $CAROL_TOKEN"

    Example output:

      < HTTP/1.1 200 OK
...

  7. Still with Carol’s token, send a request to the /status/200 endpoint. This time, the request fails because Carol’s token is not from the provider in the VirtualHostOption.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/status/200 \
-H "host: www.example.com:8080" \
--header "Authorization: Bearer $CAROL_TOKEN"
  
      curl -vik localhost:8080/status/200 \
-H "host: www.example.com:8080" \
--header "Authorization: Bearer $CAROL_TOKEN"

    Example output:

      < HTTP/1.1 401 Unauthorized
...
Jwt verification fails

  8. Delete the VirtualHostOption.

      kubectl delete VirtualHostOption jwt -n gloo-system

  9. Repeat the request to the /status/200 route with Carol’s token. Now, the request succeeds because the gateway no longer enforces a JWT policy on all its routes.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/status/200 \
-H "host: www.example.com:8080" \
--header "Authorization: Bearer $CAROL_TOKEN"
  
      curl -vik localhost:8080/status/200 \
-H "host: www.example.com:8080" \
--header "Authorization: Bearer $CAROL_TOKEN"

    Example output:

      < HTTP/1.1 200 OK
...

3: Same stage conflicts

As you saw in the previous scenario, route-level JWT policies configured in the RouteOption use the jwtProvidersStaged option to provide the JWT provider and server details. However, what happens if the gateway-level JWT policies in the VirtualHostOption are set at the same stage as the RouteOption, such as before or after external auth? In this case, the route-level JWT policy takes precedence.

  1. Update the stage of the JWT policy on the RouteOption. Note that the token source is set to the x-after-ext-auth-bearer-token header instead of the default Authorization header. This way, you can pass in both tokens on requests to the /get endpoint.

      kubectl apply -f- <<EOF
apiVersion: gateway.solo.io/v1
kind: RouteOption
metadata:
  name: jwt
  namespace: httpbin
spec:
  options:
    jwtProvidersStaged:
      afterExtAuth:
        providers:
          selfminted:
            tokenSource:
              headers:
              - header: x-after-ext-auth-bearer-token
            issuer: solo.io
            jwks:
              local:
                key: |
                  -----BEGIN PUBLIC KEY-----
                  MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp/ZO8Qhfj6kB5BxndHds
                  x12rgJ2DyU0lvlbC4Ip1zTlULV/Fuy1uAqKbBRC9IyoFiYxuWTLbvpLv5SLnrIPy
                  f4nvX4oHGdyFrcwvCtKvcgtttB363HWiG0PZwSwEn0yMa7s4Rhmy9/ZSYm+sMZQw
                  8wKv40pYnBuqRv1DpfvZLOXvICCkd5f03zv1HQXIfO3YjXOy58vOkajpzTmx4q2A
                  UilrCJcR6tBMoAph5FiJxgRmdLziKx3QXukUSNWfrFVSL+D/BoQV+2TJDZjKfPgj
                  DDMKeb2OsonQ0me3VSw2gkdnE9cyIklXcne/+oKEqineG8a12JSfEibf29iLiIXO
                  gQIDAQAB
                  -----END PUBLIC KEY-----
EOF

  2. Re-create the VirtualHostOption, this time with a jwtStaged option that is set to the same stage as the RouteOption.

      kubectl apply -f- <<EOF
apiVersion: gateway.solo.io/v1
kind: VirtualHostOption
metadata:
  name: jwt
  namespace: gloo-system
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: http
    namespace: gloo-system
  options:
    jwtStaged:
      afterExtAuth:
        providers:
          selfminted:
            issuer: solo.io
            jwks:
              local:
                key: |
                  -----BEGIN PUBLIC KEY-----
                  MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskFAGESgB22iOsGk/UgX
                  BXTmMtd8R0vphvZ4RkXySOIra/vsg1UKay6aESBoZzeLX3MbBp5laQenjaYJ3U8P
                  QLCcellbaiyUuE6+obPQVIa9GEJl37GQmZIMQj4y68KHZ4m2WbQVlZVIw/Uw52cw
                  eGtitLMztiTnsve0xtgdUzV0TaynaQrRW7REF+PtLWitnvp9evweOrzHhQiPLcdm
                  fxfxCbEJHa0LRyyYatCZETOeZgkOHlYSU0ziyMhHBqpDH1vzXrM573MQ5MtrKkWR
                  T4ZQKuEe0Acyd2GhRg9ZAxNqs/gbb8bukDPXv4JnFLtWZ/7EooKbUC/QBKhQYAsK
                  bQIDAQAB
                  -----END PUBLIC KEY-----
EOF

  3. Repeat the request to the /get endpoint with Carol’s token. The request succeeds with only Carol’s token, because the RouteOption policy takes precedence and overwrites the VirtualHostOption configuration at the same stage.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"
  
      curl -vik localhost:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"

    Example output:

      < HTTP/1.1 200 OK
...

  4. Send a request to the /status/200 endpoint without a valid token for the gateway-level JWT policy. Even though the VirtualHostOption configures a gateway-level JWT policy, the request succeeds, because the RouteOption policy takes precedence.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"
  
      curl -vik localhost:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"

    Example output:

      < HTTP/1.1 200 OK
...
Jwt is missing

4: Separate stages

Set up the RouteOption and VirtualHostOption to configure JWT policies at different stages before and after external auth. This way, the protected routes require both tokens.

  1. Update the VirtualHostOption as follows:

    • Use the beforeExtAuth stage in the jwtStage option so that the stage is different than the stage that is configured in the RouteOption.
    • Add an RBAC policy to allow tokens from the ops team, which corresponds to Bob’s token.
      kubectl apply -f- <<EOF
apiVersion: gateway.solo.io/v1
kind: VirtualHostOption
metadata:
  name: jwt
  namespace: gloo-system
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: http
    namespace: gloo-system
  options:
    jwtStaged:
      beforeExtAuth:
        providers:
          selfminted:
            issuer: solo.io
            jwks:
              local:
                key: |
                  -----BEGIN PUBLIC KEY-----
                  MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskFAGESgB22iOsGk/UgX
                  BXTmMtd8R0vphvZ4RkXySOIra/vsg1UKay6aESBoZzeLX3MbBp5laQenjaYJ3U8P
                  QLCcellbaiyUuE6+obPQVIa9GEJl37GQmZIMQj4y68KHZ4m2WbQVlZVIw/Uw52cw
                  eGtitLMztiTnsve0xtgdUzV0TaynaQrRW7REF+PtLWitnvp9evweOrzHhQiPLcdm
                  fxfxCbEJHa0LRyyYatCZETOeZgkOHlYSU0ziyMhHBqpDH1vzXrM573MQ5MtrKkWR
                  T4ZQKuEe0Acyd2GhRg9ZAxNqs/gbb8bukDPXv4JnFLtWZ/7EooKbUC/QBKhQYAsK
                  bQIDAQAB
                  -----END PUBLIC KEY-----
    rbac:
      policies:
        viewer:
          nestedClaimDelimiter: .
          principals:
          - jwtPrincipal:
              claims:
                team: ops
EOF

  2. Update the RouteOption to include an RBAC policy that allows tokens from the finance team, which corresponds to Carol’s token. In cases where multiple RBAC policies apply to a route, the RouteOption takes precedence.

      kubectl apply -f- <<EOF
apiVersion: gateway.solo.io/v1
kind: RouteOption
metadata:
  name: jwt
  namespace: httpbin
spec:
  options:
    jwtProvidersStaged:
      afterExtAuth:
        providers:
          selfminted:
            issuer: solo.io
            tokenSource:
              headers:
              - header: x-after-ext-auth-bearer-token
            jwks:
              local:
                key: |
                  -----BEGIN PUBLIC KEY-----
                  MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp/ZO8Qhfj6kB5BxndHds
                  x12rgJ2DyU0lvlbC4Ip1zTlULV/Fuy1uAqKbBRC9IyoFiYxuWTLbvpLv5SLnrIPy
                  f4nvX4oHGdyFrcwvCtKvcgtttB363HWiG0PZwSwEn0yMa7s4Rhmy9/ZSYm+sMZQw
                  8wKv40pYnBuqRv1DpfvZLOXvICCkd5f03zv1HQXIfO3YjXOy58vOkajpzTmx4q2A
                  UilrCJcR6tBMoAph5FiJxgRmdLziKx3QXukUSNWfrFVSL+D/BoQV+2TJDZjKfPgj
                  DDMKeb2OsonQ0me3VSw2gkdnE9cyIklXcne/+oKEqineG8a12JSfEibf29iLiIXO
                  gQIDAQAB
                  -----END PUBLIC KEY-----
    rbac:
      policies:
        viewer:
          nestedClaimDelimiter: .
          principals:
          - jwtPrincipal:
              claims:
                team: finance   
EOF

  3. Send a request to the /get endpoint with Carol’s token. The request fails even though Carol’s token is valid and meets the route-level RBAC policy. Instead, you need both tokens as required by the different JWT stages of the RouteOption and VirtualHostOption.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"
  
      curl -vik localhost:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"

    Example output:

      < HTTP/1.1 401 Unauthorized
...
Jwt is missing

  4. Repeat the request to the /get endpoint with both Bob and Carol’s tokens. Now, the request succeeds. Both tokens are required to pass the JWT policy at the different stages. The claims from Carol’s token passes the RBAC policy.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN" \
--header "Authorization: Bearer $BOB_TOKEN"
  
      curl -vik localhost:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN" \
--header "Authorization: Bearer $BOB_TOKEN"

    Example output:

      < HTTP/1.1 200 OK
...

5: Validation policy

In the previous scenario, you protected a route by requiring JWT authentication at two stages of a request, before and after external auth. To do so, you configured separate JWT policies at the route and gateway layers with RouteOption and VirtualHostOption resources. But what if you want to enforce just one layer of JWT policy, without being picky about which JWT is used?

You can achieve that by setting up a validation policy. The validation policy has several options as follows. For more details, see the API reference docs.

  • REQUIRE_VALID: The default value, which allows only requests that have a valid JWT.
  • ALLOW_MISSING: Let requests succeed when a JWT is missing. However, if an invalid JWT is provided, such as in an incorrect header or an expired token, the request fails.
  • ALLOW_MISSING_OR_FAILED: Let requests succeed even when a JWT is missing or fails verification, such as an expired JWT.

  1. Verify that your current setup expects two JWT tokens by sending a request to the /get endpoint with Carol’s token. The request fails even though Carol’s token is valid and meets the route-level JWT policy. Instead, you need both tokens as required by the different JWT stages of the RouteOption and VirtualHostOption.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"
  
      curl -vik localhost:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"

    Example output:

      < HTTP/1.1 401 Unauthorized
...
Jwt is missing

  2. Update the VirtualHostOption to add a validation policy that allows for a missing token. This way, you only have to include the RouteOption JWT on the /get endpoint.

      kubectl apply -f- <<EOF
apiVersion: gateway.solo.io/v1
kind: VirtualHostOption
metadata:
  name: jwt
  namespace: gloo-system
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: http
    namespace: gloo-system
  options:
    jwtStaged:
      beforeExtAuth:
        validationPolicy: ALLOW_MISSING
        providers:
          selfminted:
            issuer: solo.io
            jwks:
              local:
                key: |
                  -----BEGIN PUBLIC KEY-----
                  MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskFAGESgB22iOsGk/UgX
                  BXTmMtd8R0vphvZ4RkXySOIra/vsg1UKay6aESBoZzeLX3MbBp5laQenjaYJ3U8P
                  QLCcellbaiyUuE6+obPQVIa9GEJl37GQmZIMQj4y68KHZ4m2WbQVlZVIw/Uw52cw
                  eGtitLMztiTnsve0xtgdUzV0TaynaQrRW7REF+PtLWitnvp9evweOrzHhQiPLcdm
                  fxfxCbEJHa0LRyyYatCZETOeZgkOHlYSU0ziyMhHBqpDH1vzXrM573MQ5MtrKkWR
                  T4ZQKuEe0Acyd2GhRg9ZAxNqs/gbb8bukDPXv4JnFLtWZ/7EooKbUC/QBKhQYAsK
                  bQIDAQAB
                  -----END PUBLIC KEY-----
EOF

  3. Repeat the request to the /get endpoint with Carol’s token. Now, the request succeeds, even without Bob’s token. The validation policy at the VirtualHostOption allows the JWT to be missing on requests.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"
  
      curl -vik localhost:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"

    Example output:

      < HTTP/1.1 200 OK
...

6: Delegated routes

In a delegation scenario, the JWT policy of parent routes take precedence over child routes.

Note that this example focuses on setting up delegation with HTTPRoutes that have different RouteOption configurations. The example does not discuss gateway-level policies that are set by the VirtualHostOption. The same configuration interactions between the route-level RouteOption and the gateway-level VirtualHostOption as described in the previous scenarios still apply. For example, route-level JWT policies at the same stage as gateway-level JWT policies take precedence.

  1. Update the httpbin HTTPRoute to delegate the /get route to an httpbin-child child HTTPRoute. Leave the jwt RouteOption configuration on the /get route to keep the original route-level JWT policy.

      kubectl apply -f- <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin
  namespace: httpbin
  labels:
    example: httpbin-route
spec:
  parentRefs:
    - name: http
      namespace: gloo-system
  hostnames:
    - "www.example.com"
  rules:
    - backendRefs:
        - name: httpbin
          port: 8000
      matches:
      - path:
          type: PathPrefix
          value: /status/200
    - matches:
      - path:
          type: PathPrefix
          value: /get
      backendRefs:
      - group: gateway.networking.k8s.io
        kind: HTTPRoute
        name: httpbin-child
        namespace: httpbin
      filters:
        - type: ExtensionRef
          extensionRef:
            group: gateway.solo.io
            kind: RouteOption
            name: jwt
EOF

  2. Create the child route with an ExtensionRef that selects a different jwt-child RouteOption.

      kubectl apply -f- <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-child
  namespace: httpbin
  labels:
    example: httpbin-route
spec:
  rules:
    - backendRefs:
        - name: httpbin
          port: 8000
      matches:
      - path:
          type: PathPrefix
          value: /get
      filters:
        - type: ExtensionRef
          extensionRef:
            group: gateway.solo.io
            kind: RouteOption
            name: jwt-child
EOF

  3. Create the jwt-child RouteOption with a different JWT configuration than the parent. This JWKS has a different docs.xyz issuer than the solo.io issuer that the parent route’s separate RouteOption resource configured.

      kubectl apply -f- <<EOF
apiVersion: gateway.solo.io/v1
kind: RouteOption
metadata:
  name: jwt-child
  namespace: httpbin
spec:
  options:
    jwtProvidersStaged:
      afterExtAuth:
        providers:
          selfminted:
            issuer: docs.xyz
            jwks:
              local:
                key: |
                  -----BEGIN PUBLIC KEY-----
                  MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1SU1LfVLPHCozMxH2Mo
                  4lgOEePzNm0tRgeLezV6ffAt0gunVTLw7onLRnrq0/IzW7yWR7QkrmBL7jTKEn5u
                  +qKhbwKfBstIs+bMY2Zkp18gnTxKLxoS2tFczGkPLPgizskuemMghRniWaoLcyeh
                  kd3qqGElvW/VDL5AaWTg0nLVkjRo9z+40RQzuVaE8AkAFmxZzow3x+VJYKdjykkJ
                  0iT9wCS0DRTXu269V264Vf/3jvredZiKRkgwlL9xNAwxXFg0x/XFw005UWVRIkdg
                  cKWTjpBP2dPwVZ4WWC+9aGVd+Gyn1o0CLelf4rEjGoXbAAEgAqeGUxrcIlbjXfbc
                  mwIDAQAB
                  -----END PUBLIC KEY-----
EOF

  4. Send a request to the /get child route with Carol’s token. The request succeeds, because Carol’s token is from the solo.io issuer as required by the JWT policy of the parent route, not the docs.xyz issuer of the child route.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"
  
      curl -vik localhost:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $CAROL_TOKEN"

    Example output:

      < HTTP/1.1 200 OK
...

  5. Create an environment variable to save a JWT token for the user Dan. Dan’s JWT comes from the docs.xyz provider in the jwt-child RouteOption. Optionally, you can review the token information by debugging the token in jwt.io.

      export DAN_TOKEN=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJvcmciOiJkb2NzLnh5eiIsInN1YiI6ImRhbiIsInRlYW0iOiJvcHMiLCJpc3N1ZXIiOiJkb2NzLnh5eiIsImxsbXMiOnsiY2xhdWRlIjpbIjMuNS1zb25uZXQiXX19.fg5uMTz8dGDaIAHjKUiw2kswAiI7XT6oOWDMYTTT0BqdcFugEPDHlyLbmKoMLOGRzU_3PguY-G_NbuuooGBiLAVi4-eMv1CeZmpH68EoJy25MHSlLLHNJpgkTEwZfTISyRewgKbQYUESf20iIFwbZol-zgG_YgkO3PDTSyHmlubVUOuZCpNJgeloQO3NctxjpyC0ubBErthrES09jkS12qXWLfJI-G6TuiajZ-hLr9205_EMd4OUb6NsAORJe3TEPJuDRsgWmfScOLzruRdk_8wk32IlHBF88EmEedOmaWdyc6Rxtk-_QxUl-K4zLtg5djlGiAjv_6rP1tU-ewNDpA

  6. Send a request to the /get child route with Dan’s token. The request fails, because the child policy is overwritten by the parent route, which requires a token from the solo.io issuer, not the docs.xyz issuer.

      curl -vik http://$INGRESS_GW_ADDRESS:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $DAN_TOKEN"
  
      curl -vik localhost:8080/get \
-H "host: www.example.com:8080" \
--header "x-after-ext-auth-bearer-token: $DAN_TOKEN"

    Example output:

      < HTTP/1.1 401 Unauthorized
Jwt issuer is not configured
...

Next steps

Good job on testing so many JWT scenarios.

Next, try out an example that uses an IAM provider, such as Auth0, instead of an inline JWKS.

Cleanup

You can optionally remove the resources that you set up as part of this guide.

  1. Update the httpbin HTTPRoute resource to restore the original routing rules from the getting started guide.

      kubectl apply -f- <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin
  namespace: httpbin
  labels:
    example: httpbin-route
spec:
  parentRefs:
    - name: http
      namespace: gloo-system
  hostnames:
    - "www.example.com"
  rules:
    - backendRefs:
        - name: httpbin
          port: 8000
EOF

  2. Delete the resources that you created in this guide.

      kubectl delete RouteOption jwt -n httpbin
kubectl delete VirtualHostOption jwt -n gloo-system
kubectl delete RouteOption jwt-child -n httpbin
kubectl delete HTTPRoute httpbin-child -n httpbin