ISSUE

Actually, while trying to block requests going from the pods to different domain names, for example:

• registry.access.redhat.com
• registry.access.redhat.com.edgekey.net
• registry-1.docker.io

Here, the egressnetworkpolicy is working out for `registry.access.redhat.com` and `registry.access.redhat.com.edgekey.net`, however, for `registry-1.docker.io`, it is not denying access despite giving the deny entry.

While I did a nslookup on `registry-1.docker.io` inside the pod, I could see that there were multiple "dynamic" IPs present:

sh-4.2$ nslookup registry-1.docker.io
Server: 10.74.179.83
Address: 10.74.179.83#53Non-authoritative answer:

Name: registry-1.docker.io
Address: 52.1.121.53
Name: registry-1.docker.io
Address: 52.54.232.21
Name: registry-1.docker.io
Address: 52.5.11.128
Name: registry-1.docker.io
Address: 35.174.73.84
Name: registry-1.docker.io
Address: 3.224.175.179
Name: registry-1.docker.io
Address: 34.195.246.183
Name: registry-1.docker.io
Address: 3.94.35.164
Name: registry-1.docker.io
Address: 52.4.20.24

Often a new IP shows up when we do nslookup, and I feel this is the reason, why at times the curl is working from inside the pod even though deny entry is given, because, in our official documentation [1], we could see the following piece of information:

"Domain name updates are polled based on the TTL (time to live) value of the domain returned by the local non-authoritative servers. The pod should also resolve the domain from the same local nameservers when necessary, otherwise, the IP addresses for the domain perceived by the egress network policy controller and the pod will be different, and the egress network policy may not be enforced as expected. Since egress network policy controller and pod are asynchronously polling the same local nameserver, there could be a race condition where pod may get the updated IP before the egress controller. Due to this current limitation, domain name usage in EgressNetworkPolicy is only recommended for domains with infrequent IP address changes."

[1] https://docs.openshift.com/container-platform/3.11/admin_guide/managing_networking.html#admin-guide-limit-pod-access-egress

 
ENVIRONMENT:

• Red Hat Openshift Container Platform 3.11

STEPS TO REPRODUCE:
 
Step 1 - Verify whether you are using either ovs-multitenant or ovs-networkpolicy:

# oc get clusterNetwork

* You must have the ovs-multitenant or ovs-networkpolicy plug-in enabled in order to limit pod access via egress policy.

Step 2 - Create an egress file, say `egressFirewall.yaml`:
 
[quicklab@master-0 ~]$ cat egressFirewall.yaml 
 

---
kind: EgressNetworkPolicy
apiVersion: v1
metadata:
  name: default
spec:
  egress:
  - type: Deny
    to:
      dnsName: registry.access.redhat.com
  - type: Deny
    to:
      dnsName: registry.access.redhat.com.edgekey.net
  - type: Deny
    to:
      dnsName: registry-1.docker.io
  - type: Allow
    to:
      cidrSelector: 0.0.0.0/0
~~~

[quicklab@master-0 ~]$ oc create -f egressFirewall.yaml
egressnetworkpolicy.network.openshift.io/default created

[quicklab@master-0 ~]$ oc rsh webconsole-85494cdb8c-bhdnp

sh-4.2$ curl -kv https://registry-1.docker.io
* About to connect() to registry-1.docker.io port 443 (#0)
*   Trying 3.223.220.229...
* Connection timed out
*   Trying 52.1.121.53...
* Connected to registry-1.docker.io (52.1.121.53) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=*.docker.io
* start date: May 23 00:00:00 2020 GMT
* expire date: Jun 23 12:00:00 2021 GMT
* common name: *.docker.io
* issuer: CN=Amazon,OU=Server CA 1B,O=Amazon,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: registry-1.docker.io
> Accept: */*
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Date: Fri, 19 Jun 2020 05:48:11 GMT
< Content-Length: 0
< Strict-Transport-Security: max-age=31536000
<
* Connection #0 to host registry-1.docker.io left intact