Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1756312

Summary: Network Policy wrongly enforced due to wrong pod IP (Kuryr)
Product: OpenShift Container Platform Reporter: Maysa Macedo <mdemaced>
Component: NetworkingAssignee: Maysa Macedo <mdemaced>
Networking sub component: kuryr QA Contact: Jon Uriarte <juriarte>
Status: CLOSED ERRATA Docs Contact:
Severity: urgent    
Priority: urgent CC: asegurap, bbennett, juriarte, ltomasbo
Version: 4.2.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:
: 1757561 (view as bug list) Environment:
Last Closed: 2020-05-13 21:25:38 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:
Bug Depends On:    
Bug Blocks: 1757561    

Description Maysa Macedo 2019-09-27 11:07:28 UTC 
Description of problem:

We are retrieving the pod IP from a nonexistent annotation field, when should be from the annotations in the pod metadata. Also, when the Pod is not yet annotated we keep retrying
with the same not annotated pod object, causing the Kuryr controller to restart.

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

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
- Network Policy enforced with a security group rule with no remote_ip
- Kuryr Controller restart


Expected results:
- Network Policy enforced with a security group rule with a remote_ip pointing to the Pod IP
- No Kuryr Controller restart


Additional info:
Comment 1 Maysa Macedo 2019-09-27 11:23:32 UTC 
To reproduce you can:
1. Create a network policy allowing ingress from a pod that does not contains "pod-name" label. As shown in a code fragment from Upstream k8s e2e tests:

policy := &networkingv1.NetworkPolicy{
ObjectMeta: metav1.ObjectMeta{
        Name: "allow-pod-b-via-pod-selector",
},      
Spec: networkingv1.NetworkPolicySpec{
        PodSelector: metav1.LabelSelector{
                MatchLabels: map[string]string{
                        "pod-name": podServerLabelSelector,
                },      
        },      
        Ingress: []networkingv1.NetworkPolicyIngressRule{{
                From: []networkingv1.NetworkPolicyPeer{{
                        PodSelector: &metav1.LabelSelector{
                                MatchExpressions: []metav1.LabelSelectorRequirement{{
                                        Key:      "pod-name",
                                        Operator: metav1.LabelSelectorOpDoesNotExist,
                                }},     
                        },      
                }},     
        }},     
},      
} 
2. Create a pod with the "pod-name" label and verify it doesn't connects
3. Create another pod without the "pod-name" label and very it connects
Comment 3 Jon Uriarte 2019-10-03 16:17:20 UTC 
Verified on an OCP 4.2 cluster (4.2.0-0.nightly-2019-10-02-001405) with Kuryr-controller image from OCP 4.3 (4.3.0-0.ci-2019-10-02-101344),
which includes the fix.
Verified that the fix does not add new regressions as well.

$ oc get pods -n openshift-kuryr kuryr-controller-5744b8d79d-wpdjl -o yaml | grep image
   image: registry.svc.ci.openshift.org/ocp/4.3-2019-10-02-101344@sha256:313a91b60fb5f49ece7e351ffee86e6f799b4399025d07cff9df8fec5adb5d06

It was not possible to verify on OCP 4.3 cluster as there are no nightly builds available at the moment.
Comment 6 Jon Uriarte 2019-10-18 08:04:45 UTC 
Verified on OCP 4.3.0-0.nightly-2019-10-17-061631 build on top of OSP 13 2019-10-01.1 puddle.

release image: registry.svc.ci.openshift.org/ocp/release@sha256:2cafe25ec1ed2dfdec361cde13b4461d2a30194d0b41fbd1c6d3fad5ab34ca05

K8s NP (test/e2e/network/network_policy.go) tests passed.
Comment 8 errata-xmlrpc 2020-05-13 21:25:38 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