In AKS: IP range filtering at ingress when Load Balancer behind a proxy (externalTrafficPolicy is Local)

Hi !

Here is my use case:

I have a Microsoft AKS cluster with Istio installed.
The Load Balancer is behind a Microsoft Azure Frontdoor (proxy)
I configured an ingress with externalTrafficPolicy==Local

I would like to do IP based filtering at the ingress level, using resource AuthorizationPolicy

When a request arrives at Istio:

  • x-forwarded-for header is <IP source client>,<IP Frontdoor proxy>
  • x-azure-clientip header is <IP source client> (header set by the Azure Frontdoor proxy)
  • sourceIP: is <IP Frontdoor proxy>:<port>
  • remoteIP is <IP Frontdoor proxy>:<port>
  • directRemoteIP is <IP Frontdoor proxy>:<port>

First, it seems that using remoteIpBlocks does not work because x-forwaded-for is a list of IPs and it is not checking all of them ? (taking 2nd one for the remote.ip and not the first one)

Then I used a rule instead to check IP against request.headers[x-azure-clientip]:
- when:
- key: request.headers[x-azure-clientip]
- "<IP to whitelist 1>"
- "<IP to whitelist 2>"

It worked. However with this I cannot allow a range of IP (with CIDR e.g xx.xx.xx.xx/22)

So now I am thinking of using EnvoyFilter to:

  • take IP from x-azure-clientip if exists
  • Rewrite source IP with this IP
    And then I would use ipBlocks in AuthorizationPolicy which can process IP ranges

Is it the best strategy ? Does someone encountered the same kind of challenge ?

Thank you !

1 Like

Hello! I have the exact same issue as you. Did you find a solution to this?

It seem strange to me that Istio doesn’t have configuration option to control which header to look at.

Hi @Dogsbody

Actually I dig further on existing issues and I found:

So it seems it is a common use case

I haven’t tried yet but I am thinking of using envoyFilter at ingress level to rewrite source IP, and do a AuthorizationPolicy on ipBlocks at VirtualService level.

1 Like

Have you tried ipBlocks in your AuthorizationPolocy? According to this artcile when externalTrafficPolicy: Local is set that’s what you should use.

Hello @ams0

I tried ipBlocks without success because the client IP is set with IP of first proxy (Azure FrontDoor in my use case), and not the real remote client IP. I guess it works fine if the cluster is not behind a proxy (so reached out directly by client IP). And as I wrote in the issue description, remoteIpBlocks does not seem to work on x-forwarded-for that contain a list of IPs ( <IP source client>,<IP Frontdoor proxy>).