Hide Forgot
Description of problem: oc v3.3.0.24-dirty kubernetes v1.3.0+507d3a7 Version-Release number of selected component (if applicable): Create a service with a manually-created Endpoints object pointing to an IP address first, then create a egressnetworkpolicy which defined to block the IP address in endpoints. But the egressnetworkpolicy doesn't work. How reproducible: Always Steps to Reproduce: 1.Create a new project: p1, then create a service with endpoints # oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/networking/egressnetworkpolicy/service_endpoint.json # oc get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE selector-less-service 172.30.10.219 <none> 10086/TCP 14s 2. Create a pod to access the service # oc get endpoints NAME ENDPOINTS AGE selector-less-service 10.3.11.3:2015 14s # oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/networking/pod-for-ping.json # oc rsh hello-pod / # curl 172.30.10.219:10086 404 Not Found/ 3. Create a egressnetworkpolicy by admin # oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/networking/egressnetworkpolicy/533253_policy.json -n p1 4. Try to access the service in pod again 5. Check the openflow Actual results: step4: The service is still available # oc rsh hello-pod / # curl 172.30.10.219:10086 404 Not Found/ step5: cookie=0x0, duration=863.828s, table=9, n_packets=0, n_bytes=0, priority=1,ip,reg0=0xc00176,nw_dst=10.3.0.0/16 actions=drop Expected results: step4 Should return / # curl 172.30.10.219:10086 curl: (7) Failed to connect to 172.30.10.219 port 10086: Host is unreachable Additional info: If we create the egressnetworkpolicy first, then create the service and endpoints, the service is unreachable. But then we delete the egressnetworkpolicy, the service is still unreachable. Detail steps as below: 1. Create a new-project p2 2. Create egressnetworkpolicy by admin # oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/networking/egressnetworkpolicy/533253_policy.json -n p2 3. Create service and endpoints # oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/networking/egressnetworkpolicy/service_endpoint.json # oc get endpoints NAME ENDPOINTS AGE selector-less-service 10.3.11.3:2015 23m # oc get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE selector-less-service 172.30.0.106 <none> 10086/TCP 23m 4. Create a pod to access the service inside the pod # oc rsh hello-pod / # curl 172.30.0.106:10086 curl: (7) Failed to connect to 172.30.0.106 port 10086: Host is unreachable 5. Delete the egressnetworkpolicy by admin 6. Try to access the service inside pod again, the service is sitll unreachable curl: (7) Failed to connect to 172.30.0.106 port 10086: Host is unreachable 7. Check the openflow The openflow already disappeared when delete the egressnetworkpolicy
This is the same underlying problem as bug 1367364; the proxy endpoint filterer doesn't get immediately rerun when the firewall rules change. It does *eventually* get updated (within a few minutes). Although theoretically security-problem-ish, I felt like this wasn't a big deal, because it's not the sort of thing that's going to be a problem in real-world use cases. (You would expect admins to set up firewalls for projects before any pods/services are created in the project, rather than letting the project admin go crazy for a bit and then belatedly boxing them in.) But it could be fixed. (Which would fix 1367364 too.)
*** This bug has been marked as a duplicate of bug 1367364 ***
Hi Ben, I think the bug may not same as #bug 1367364. In #bug 1367364, we could get the expected behavior after a few minutes. It may be a delay issue. But in #bug 1369750, even I wait for more than half an hour, the egressnetworkpolicy still can not block the endpoint which created before egressnetwork policy, we still could not get the expected behavior. this may be a function issue.
Issue have been fixed on oc v3.3.0.27 kubernetes v1.3.0+507d3a7
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1933