Bug 1369750

Summary: [networking_public_244] The egressnetworkpolicy can not block the endpoint which created before egressnetwork policy
Product: OpenShift Container Platform Reporter: Yan Du <yadu>
Component: NetworkingAssignee: Dan Winship <danw>
Status: CLOSED ERRATA QA Contact: Meng Bo <bmeng>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.3.0CC: aos-bugs, bbennett
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-27 09:45:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Yan Du 2016-08-24 10:09:18 UTC
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

Comment 1 Dan Winship 2016-08-24 13:02:53 UTC
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.)

Comment 2 Ben Bennett 2016-08-24 13:10:46 UTC

*** This bug has been marked as a duplicate of bug 1367364 ***

Comment 3 Yan Du 2016-08-25 06:53:07 UTC
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.

Comment 5 Yan Du 2016-08-30 02:00:31 UTC
Issue have been fixed on 

oc v3.3.0.27
kubernetes v1.3.0+507d3a7

Comment 7 errata-xmlrpc 2016-09-27 09:45:48 UTC
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