`auth.custom`: Allow specifying `path` for auth request

[mbana]

In the example below, we should only get an auth call on auth-custom-path:80/custom-path, not on auth-custom-path:80/uuid.

Example

apiVersion: gateway.kusk.io/v1alpha1
kind: API
metadata:
  name: auth-custom-path
  namespace: default
spec:
  fleet:
    name: default
    namespace: default
  spec: |
    openapi: 3.0.0
    info:
      title: auth-custom-path
      description: auth-custom-path
      version: 0.1.0
    x-kusk:
      auth:
        custom:
          host:
            port: 80
            hostname: auth-custom-path
            path: "custom-path"
      upstream:
        service:
          name: auth-custom-path-httpbin
          namespace: default
          port: 80
    paths:
      "/uuid":
        get:
          description: Returns UUID4.
          operationId: "/uuid"
          responses: {}

Log

Calling /uuid (curl -v 192.168.49.2/uuid) results in a request to the auth server with the URL set to /uuid instead of /custom-path:

GET /uuid HTTP/1.1
Host: 192.168.49.2
Content-Length: 0
X-Envoy-Expected-Rq-Timeout-Ms: 32000
X-Envoy-Internal: true
X-Forwarded-For: 172.17.0.5

Even though the filter has been configured as:

...
  {
      "name": "envoy.filters.http.ext_authz",
      "typed_config": {
          "@type": "type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz",
          "http_service": {
              "server_uri": {
                  "uri": "auth-custom-path:80/custom-path",
                  "cluster": "auth-custom-path-80",
                  "timeout": "32s"
              },
              "authorization_response": {
                  "allowed_upstream_headers": {
                      "patterns": [
                          {
                              "exact": "x-current-user",
                              "ignore_case": true
                          }
                      ]
                  }
              }
          },
          "include_peer_certificate": true,
          "transport_api_version": "V3"
      }
  },
...

That is, we expect http_service.server_uri.uri to be used.

Limitations

Probably not possible due to some existing Envoy issues:

• https://github.com/envoyproxy/envoy/issues/10104.
• https://github.com/envoyproxy/envoy/issues/5357.
• https://github.com/envoyproxy/envoy/issues/5357#issuecomment-819075129 ("The current implementation expects the authentication endpoint to accept arbitrary methods/paths ...").