I’m struggling to get envoy’s grpc client to work with a service internal to the istio mesh. I’m wondering if anyone has some advice.
My setup is that an istio ingress forwards requests to another service implementing the ext_authz grpc interface. I have been using the ext_authz filter fine with the google_grpc client, but that does not allow me to make use of envoy’s builtin retry logic. So, I want to switch over.
The problem is that the authz requests fail at the istio sidecar with a DPE response flag. I suspect the issue is due to the authority that envoy puts into the request – the cluster name – which includes the
| character. If I disable sidecar injection for the authz pod, my requests get through and are processed fine.
This is the filter config I’m using:
--- apiVersion: networking.istio.io/v1alpha3 kind: EnvoyFilter metadata: name: ext-authz-grpc spec: workloadSelector: labels: app: istio-ingressgateway configPatches: - applyTo: HTTP_FILTER match: context: GATEWAY listener: portNumber: 443 patch: operation: INSERT_BEFORE value: name: "envoy.ext_authz" config: grpc_service: envoy_grpc: cluster_name: outbound|9191||policy-agent-grpc.ingress-policy-agent.svc.cluster.local timeout: 5.000s initial_metadata: - key: x-envoy-retry-on value: "connect-failure,refused-stream,unavailable,cancelled,resource-exhausted,5xx,retriable-status-codes" - key: x-envoy-max-retries value: "5"
Previously, the grpc_service section looked like this:
grpc_service: google_grpc: target_uri: "policy-agent-grpc.ingress-policy-agent.svc.cluster.local:9191" stat_prefix: "ext_authz"
Does anyone have some thoughts on why this could be happening?
Is there a way I can force the istio cluster name to change? Is there a way I can make envoy not fail validation?