Terminating MTLS in ingressgateway - what about authorization?

[jesper]

Well, nothing yet I see

Partially inspired by this:

End User Certificate Authentication

Yes, this is how we modeled it: Request from client comes in to Ingress Gateway Ingress Gateway checks certificate fingerprint against a whitelist 2.1) If fingerprint exists in whitelist (populated by a secret), request enters the cluster 2.2) If fingerprint doesn’t exist, request is rejected My investigation has led me to either an EnvoyFilter (native to Istio/Envoy) or using Gloo with a function level route that will check this, however, I’d like to keep Istio’s Ingress Gateway if possibl…

I’ve played with an envoy filter in my AuthorizationPolicy:

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: ingressgateway-authz
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - to:
    - operation:
        ports: ["443","9443"]
        hosts:
        - "pow.servicemesh.mybox"
    when:
    - key: experimental.envoy.filters.network.client_ssl_auth[certificates]
      values:
      - "[[fingerprint_sha256, 5234981512daca66a79ba1cc2cc5c759d636af07a6dd360077ae42d209b3306a]]"

But alas no success yet. I’m definitely still using the filter in wrong way. Any insight on this?

Even when I fix the envoy filter request I would still very much like to request built in Istio functionality to do authorization on certificates after authenticating them via SDS. E.g. via the hash value.

Best regards
Jesper Berggren