Another AuthorizationPolicy Question - IP Whitelist for VirtualService

Security
1

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.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  namespace: dit
  name: core-config-allow
spec:
  selector:
    matchLabels:
      app: service-core
  action: DENY
  rules:
    - from:
        - source:
            notNamespaces: ["ns1", "ns2", "ns-system", "istio-system"]
    - from:
        - source:
            notIpBlocks: ["172.23.0.0/16"]

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?

2

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?

3

Is Mutual TLS enabled?

4

Hi,

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.

5

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

6

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. “172.23.0.1”) still get denied? That is strange and I suggest to check the debug logging in envoy to verify the request: Istio / Security Problems