Authorization Policy IP allow/deny not working on services different than ingress-gateway

Security
1

Hi everyone,

Currently, I’m trying to allow/deny incoming traffic to a specific service according to the ip of the request.

The example on this page Authorization on Ingress gateway, where the usage of source.ipBlocks to allow/deny external incoming traffic worked as expected.

When that same authorization policy was now targeted to other pods on a different namespace, it stops working. The only way to make it work is by evaluating a specific header[X-Envoy-External-Address] to the address I’m looking to block/allow. This is not an appropriate workaround as it doesn’t support CIDR.

This the authorizationpolicy I used on the first example which worked.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: ingress-policy
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  action: DENY
  rules:
  - from:
    - source:
       ipBlocks: ["186.116.204.204"]

The authorization policy used on other namespace that didn’t work:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin-policy
  namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - from:
    - source:
        ipBlocks: ["186.116.204.204"]

The configuration of externalTrafficPolicy is already set to local. When logging the istio-proxy on the specific pod, the origin IP is printed with its expected value whenever a new incoming request is received.

Is this the expected behavior or am I missing something?

2

I guess the reason why it’s stop working when in non ingress pod is because the sourceIP attribute will not be the real client IP then.

According to https://github.com/istio/istio/issues/22341, (not done yet) this aims at providing better support without setting k8s externalTrafficPolicy to local, and supports CIDR range as well.

But what I’m not sure is: after routing from ingress gateway, to the httpbin pod, whether the remoteIP attribute will be propogated as the same? @YangminZhu Do you know about that?

1 Like
3

Thanks for your response.

That PR is talking about a specific use case when a proxy is sitting in front of the ingress-gateway, affecting the original ip. Do you think remoteIP will also be useful for the case I presented?

If that’s the case, I might as well try to apply an EnvoyFilter manifest into httpbin pod with an RBAC filter. But it would be easier to just know if remoteIP actually propagates as the same, as you just asked in your question.

4

Got and example working successfully using EnvoyFilters, specifically with remote_ip condition applied on httbin.

Sharing the manifest for reference.

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: httpbin
  namespace: foo
spec:
  workloadSelector:
    labels:
      app: httpbin
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          filterChain:
            filter:
              name: "envoy.http_connection_manager"
              subFilter:
                name: "envoy.router"
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.rbac 
          config:
            rules:
              action: ALLOW
              policies:
                "ip-premissions":
                  permissions:
                    - any: true
                  principals:
                    - remote_ip:
                        address_prefix: 186.168.165.52
                        prefix_len: 32
5

This is great! Basically you confirmed the httpbin can see the remote_ip address as original client Ip address right? even after the ingress gateway route to the httpbin pod.

6

Yep, apparently that’s exactly what’s happening, used external ip addresses on the manifest and conditions matched as expected on a pod different than istio-ingressgateway.