Syntax suggestion: authorization policy behind a reverse proxy

I want my telemetry to be visible to whitelisted IPs only. My cluster lives behind a reverse proxy, so I can’t simply use source.ip or from -> source -> ipBlocks because they only “see” the backside of the proxy.

This AuthorizationPolicy works, with my telemetry living on a separate subdomain:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: ingress-policy
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  action: ALLOW
  rules:
    - to:
        - operation:
            notHosts:
              - telemetry.example.com
    - to:
        - operation:
            hosts:
              - telemetry.example.com
      when:
        - key: request.headers[x-forwarded-for]
          values:
            - "12.34.56.78*"

The only problem I have with it is that it feels a bit ugly. Headers and behavior for reverse proxies are reasonably standard, are they not? It feels to me like there should be a more direct way of expressing this rule. Maybe something like:

    - from:
        - source:
            proxiedIPBlocks[ "12,34,56,78/32" ]
      to:
        - operation:
            hosts:
              - telemetry.example.com

Or if that isn’t workable, maybe the documentation could have an example of how to filter by client IP from behind a reverse proxy. I had to do more digging than I care to admit to figure this out.

we are adding a new field remoteIpBlocks to solve this problem in 1.8, see the design doc https://docs.google.com/document/d/1gf0LKom9RpBjux6FYvdKCLu4v2paVZnbuPRSRyGJ4Dg/edit for more details.

Oh, excellent.

I must say that I like your option #3 best, using only ipBlocks/notIpBlocks and keeping the proxy part of the configuration to the numTrustedProxies field. That feels like a cleaner separation of concerns.

But remoteIpBlocks/notRemoteIpBlocks works well if there’s some possible use case for distinguishing proxied vs non-proxied clients.