Listchecker adapter not working with values of type ip_address

Policies and Telemetry
1

Hi,

i’ve noticed that it’s currently not possible to have black/whitelists based on source.ip of incoming data. I initially thought it could be done with listentry template in combination with listchecker adapter. But eventually i found out that the value field of listentry is of type String, source.ip though is of type IP_ADDRESS. Of course this lead to a mismatch in rule validation in mixer and my rules didn’t got applied.

I think this problem was not yet “discovered” because Istio is (in my point of view) mainly focusing on managing HTTP traffic (where IP adresses are at times available in http headers in string types), whereas i’m more interested in managing TCP traffic (where i do not have ip adresses in form of string).

To overcome this issue i’ve created a fork of istio where i’ve introduced a new template called “ListIpEntry” and made it also available to listchecker adapter. It’s basically a clone of listentry where i would call .String() method on passed IP_ADDRESS in HandleListIpEntry of listchecker.

So far it works very well :slight_smile:

Please let me know what you think on this topic and my fork.

Regards, Dirk

2

Dirk,

I believe work was done very recently to address this very issue – though my memory of the resolution is a bit hazy after the holidays. This was raised in the P&T WG meeting a few weeks back.

You might want to look at https://github.com/istio/istio/pull/10444 and the initial bug report of https://github.com/istio/istio/issues/10468. There was another PR that I can’t remember right now that fixed an underlying bug in valuetype handling within Mixer that may also have been preventing proper IP_ADDRESS use in listchecker.

I believe, at one point, the idea was to enable more powerful list checking (use subnets, etc.). Let’s discuss again at the next P&T WG meeting to get some resolution.

Thanks for listening,
Doug.

3

Follow-up: I just tested from the tip of the release-1.1 branch, and this is working as expected.

Rule configs:

apiVersion: "config.istio.io/v1alpha2"
kind: handler
metadata:
  name: ipranges
  namespace: istio-system
spec:
  compiledAdapter: listchecker
  params:
    overrides: ["192.168.0.0/16", "10.0.0.0/8"] 
    entryType: 2
    blacklist: false
---
apiVersion: "config.istio.io/v1alpha2"
kind: listentry
metadata:
  name: sourceip
  namespace: istio-system
spec:
  value: source.ip
---
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: iprule
  namespace: istio-system
spec:
  # If an attribute could be potentially absent, use the '|' operator
  # to provide a default value. In the below example if 'destination.labels'
  # is absent, "unknown" is used in its place (this happens in non kubernetes env).
  match: destination.workload.name == "iptest"
  actions:
  - handler: ipranges
    instances:
    - sourceip.listentry

And then ran the following commands:

$ KUBECONFIG=~/.kube/config mixs server --configStoreURL=fs://$(pwd)/mixer/testdata/config

and

$ mixc check -a source.ip=a:96:0:5 -s destination.workload.name="iptest",destination.port=200,destination.service="ingress2.istio-system.svc.cluster.local",context.protocol="http" -i response.duration=0.02 -i response.size=1024 -t request.time=2006-01-12T13:45:45Z,response.time=2006-01-12T13:45:45Z

And got:

Check RPC completed successfully. Check status was OK
  Valid use count: 10000, valid duration: 5m0s
  Referenced Attributes
    context.reporter.kind ABSENCE
    destination.ip ABSENCE
    destination.namespace ABSENCE
    destination.service EXACT
    destination.uid ABSENCE
    destination.workload.name EXACT
    request.headers ABSENCE
    source.ip EXACT
    source.uid ABSENCE

Running with a non-included ip: $ mixc check -a source.ip=5:96:0:5 -s destination.workload.name="iptest",destination.port=200,destination.service="ingress2.istio-system.svc.cluster.local",context.protocol="http" -i response.duration=0.02 -i response.size=1024 -t request.time=2006-01-12T13:45:45Z,response.time=2006-01-12T13:45:45Z

...
Check RPC completed successfully. Check status was PERMISSION_DENIED (ipranges.istio-system:5.150.0.5 is not whitelisted)
  Valid use count: 10000, valid duration: 5m0s
4

Hi Douglas,

thanks for your help. I was only checking with latest release branch 1.0.3. instead of pre-release 1.1.

I can confirm that the problem i described is solved in 1.1 and is working as expected :slight_smile:

Regards, Dirk