EnvoyFilter for ext-authz

Security
1

I’m having trouble configuring an external authorization filter with Istio. I’ve written a filter that should be applied to my gRPC service requests:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ext-authz
spec:
  filters:
  - insertPosition:
      index: FIRST
    listenerMatch:
      listenerType: SIDECAR_INBOUND
      listenerProtocol: HTTP
    filterType: HTTP
    filterName: "envoy.ext_authz"
    filterConfig:
      grpc_service:
        envoy_grpc:
          cluster_name: auth
      failure_mode_allow: false
  - insertPosition:
      index: FIRST
    listenerMatch:
      listenerType: SIDECAR_INBOUND
      listenerProtocol: TCP
    filterType: NETWORK
    filterName: "envoy.ext_authz"
    filterConfig:
      grpc_service:
        envoy_grpc:
          cluster_name: auth
      failure_mode_allow: false

The filter seems to be intercepting my requests because I’m getting permission denied responses. However in my gRPC service I’m not actually receiving or vetting the auth request (I’ve added a log in my service to output an incoming unary request).

I’m wondering if my cluster_name is incorrect. The documentation in Istio and Envoy aren’t clear as to what “cluster_name” should actually be. In the above example I’m feeding it the Service name I’ve setup. I’ve seen some example where the cluster_name is referred to as:

cluster_name: "outbound|8448||auth.default.svc.cluster.local"

I’m not sure which one is accurate. Also how can I review logs for this call to help troubleshoot the request once I determine the correct cluster_name?

Thanks.

2

Some extra information. I pulled the logs from the Gateway and noticed the following error:

[external/envoy/source/common/config/grpc_mux_subscription_impl.cc:73] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) 0.0.0.0_31400: Unable to parse JSON as proto (INVALID_ARGUMENT:grpc_service:
Proto field is not repeating, cannot start list.):
{"failure_mode_allow":false,"grpc_service":[{"envoy_grpc":{"cluster_name":"outbound|8448||auth.default.svc.cluster.local"}}]}

I’m using a definition that I see repeated quite a bit. Also I ran it through a YAML to JSON converted and it doesn’t render as a list beneath grpc_service. It’s just a regular propery.

I suspect this might be a bug but I can’t easily tell if I’m just doing something incorrectly.

3

That sounds like a bug; what version of Istio are you using?

4

Version 1.2.4

I’m having a bit of a hard time replicating it. Am I specifying the cluster_name correctly at least? lol.

5

Whether the cluster name is correct depends on what you are trying to reach and how it was defined. The most direct thing to do is to exec into the Istio-proxy pod, and

curl http://localhost:15000/clusters

—this should dump a list of all the clusters the proxy knows about, and you can check the name.

6

Yup looks like I defined it correctly. Strange.

Once I apply the rule the gateway throws a 403. I have gRPC DEBUG on to warn me when the receives receives when anything is connecting and it’s not even showing an attempt. Something internally is blocking the filter.

This seems like a pretty basic implementation, I wonder if others have encountered the same problem.