Bug 1745028

Summary: networkpolicy - specifying protocol and not specifying port results in traffic being blocked to pods in that project
Product: OpenShift Container Platform Reporter: David Caldwell <dcaldwel>
Component: NetworkingAssignee: Alexander Constantinescu <aconstan>
Networking sub component: openshift-sdn QA Contact: zhaozhanqi <zzhao>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: medium CC: aconstan, aos-bugs, cdc, erich, jokerman, rkrawitz, weliang
Version: 3.11.0   
Target Milestone: ---   
Target Release: 4.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-01-23 11:05:22 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 David Caldwell 2019-08-23 13:53:10 UTC
Description of problem:

In a networkpolicy, when a protocol is specified but the port is not, traffic is blocked to all pods in that project.

This behaviour is counter to what is specified in https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#networkpolicyport-v1-networking-k8s-io and in https://docs.google.com/document/d/1cTA_c1qahzZ9nDI-h6Vp9-9_kCB-kk1cw91K0qRjI84/edit


Version-Release number of selected component (if applicable):

3.11


Steps to Reproduce:

1. Create a test project (eg, "p1").
2. Create two pods in the project that can easily verify that traffic is flowing (eg, a simple http pods).
3. Label the pods so that it can be identified by a networkpolicy (eg, "app=p1" and "app=other").
4. Verify that no networkpolicy objects are applied to any project.
5. Verify that you can curl the pods successfully.
6. Create an ingress networkpolicy such as this (note that the label targets one pod and that the port is not specified):

{
    "apiVersion": "extensions/v1beta1",
    "kind": "NetworkPolicy",
    "metadata": {
        "name": "port-defined-only-by-protocol",
        "namespace": "p1"
    },
    "spec": {
        "ingress": [
            {
                "ports": [
                    {
                        "protocol": "TCP"
                    }
                ]
            }
        ],
        "podSelector": {
            "matchLabels": {
                "app": "p1"
            }
        },
        "policyTypes": [
            "Ingress"
        ]
    }
}


7. Try again to curl the pods - it _should_ succeed according to the docs linked above but both pods will fail to respond.
8. Edit the network policy adding a port (eg, 80 or 8080, whatever is appropriate for the image you are using).
9. Curl again. It should and will succeed.


Actual results:

No traffic ingresses to any pod in the project.


Expected results:

Not specifying the port should allow traffic of the specified protocol to flow to _any_ port. Also, not specifying a port, should not block traffic to pods that the policy is not targeting.


Additional info:

It is possible that this behaviour is by design but looking at the description of the behaviour when not specifying a port, it looks like either a bug in networkpolicy implementation or some sort of docs bug.

It is also possible that there is an issue or intended behaviour using 'matchLabels' with a 'ports' block but I cannot find mention of this.

Comment 6 Casey Callendrello 2019-09-04 11:59:58 UTC
Yup, that looks like a bug. As a workaround, don't specify the protocol and everything should work.

Comment 14 errata-xmlrpc 2020-01-23 11:05:22 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-2020:0062