Another AuthorizationPolicy Question - IP Whitelist for VirtualService

Hello, I am using istio 1.8. I have a single Gateway with 10+ virtual services attached to it, each with a routing rule that forwards traffic to different pods.

We need to block all http requests to a service called “service-core” except from within the kubernetes cluster, from a select namespaces AND from a certain IP ranges.

This is what I’ve come up with

I have istio enabled on all namespaces mentioned below. The intention is to make sure that only the allowed namespaces can communicate with the workload and allowed IP ranges.

kind: AuthorizationPolicy
  namespace: dit
  name: core-config-allow
      app: service-core
  action: DENY
    - from:
        - source:
            notNamespaces: ["ns1", "ns2", "ns-system", "istio-system"]
    - from:
        - source:
            notIpBlocks: [""]

When applying this, I get “RBAC: access denied” from both an IP address outside of that range and also the same error when I access the workload from “ns1”.

I checked the official documentation of authorization, however I don’t see this is working on my cluster. Is there anything wrong with the above?

Don’t see anything obviously wrong with the above policy. But just curious - since your goal was to whitelist communication to an app ONLY from a namespace or CIDR range, why not have an ALLOW policy and flip the NotNamespaces to Namespaces and notIPBlocks to IPBlocks?

Is Mutual TLS enabled?


I actually tried the ALLOW at first, but for some reason it didn’t work. Then tested the DENY based on a search result, but didn’t work either. I posted the latest test here.

It is the default istio installation so I believe it is enabled but not enforced. I can see the lock icon on kiali which confirms that mtls is enabled

The policy denies requests from source not in the given namespace OR not in the given IpBlocks.

Do you mean your request within the namespace (e.g. “ns1”) and also within the ipBlocks (e.g. “”) still get denied? That is strange and I suggest to check the debug logging in envoy to verify the request: Istio / Security Problems