DNS lookup still getting blocked even when authorized

3/18/2021

My rule allowing DNS with Calico's Network Policy isn't working. Using CURL with a DNS is still blocked !

My use case : I want all external networking to be dropped except communication to an S3 service. Allowing ONLY the S3's ip works as everything else is blocked except the IP I have set. But using the DNS associated to this IP is also getting blocked and I don't know why.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-egress-external
  namespace: demo
spec:
  order: 2
  selector:
    color == 'red'
  types:
    - Egress
  egress:
    - action: Allow
      protocol: UDP
      destination:
        ports:
        - 53

This should allow any pods with the label color: red to communicate with a DNS.

I also have a deny rule set as follow:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: demo
spec:
  order: 1
  selector: all()
  types:
  - Egress

And finally a rule to allow a certain IP to go through:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-egress-external
  namespace: demo
spec:
  order: 3
  selector:
    color == 'red'
  types:
    - Egress
  egress:
    - action: Allow
      destination:
        nets:
        - <some_ip>/32

But when I curl my DNS which should resolve into "\<some_ip>", the request gets blocked. Though curling <some_ip> directly works.

Any help would be appreciated,
Thx


Edit 1

For instance:

With policy UP

  • Authorized my targeted service IP
  • Authorized DNS lookup
$ curl <targeted_dns> -v
* Expire in 0 ms for 6 (transfer 0x5638bf7edfb0)
* Expire in 1 ms for 1 (transfer 0x5638bf7edfb0)
* Expire in 0 ms for 1 (transfer 0x5638bf7edfb0)
* Expire in 1 ms for 1 (transfer 0x5638bf7edfb0)
* Expire in 0 ms for 1 (transfer 0x5638bf7edfb0)
* Expire in 0 ms for 1 (transfer 0x5638bf7edfb0)
* Expire in 1 ms for 1 (transfer 0x5638bf7edfb0)
[timeout for ever]

<targeted_dns> should have been resolved and then the resulting IP should have been authorized to go through as it has been authorized manualy.

-- Doctor
calico
flannel
kubernetes
kubernetes-networkpolicy
project-calico

0 Answers