Bug 1757561 - Network Policy wrongly enforced due to wrong pod IP (Kuryr)
Summary: Network Policy wrongly enforced due to wrong pod IP (Kuryr)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 4.2.z
Assignee: Maysa Macedo
QA Contact: Jon Uriarte
URL:
Whiteboard:
Depends On: 1756312
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-01 19:42 UTC by Ben Bennett
Modified: 2019-10-30 04:45 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1756312
Environment:
Last Closed: 2019-10-30 04:44:56 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift kuryr-kubernetes pull 44 None None None 2019-10-18 08:06:25 UTC
Red Hat Product Errata RHBA-2019:3151 None None None 2019-10-30 04:45:07 UTC

Description Ben Bennett 2019-10-01 19:42:23 UTC
+++ This bug was initially created as a clone of Bug #1756312 +++

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:

--- Additional comment from Maysa Macedo on 2019-09-27 07:23:32 EDT ---

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

--- Additional comment from Ben Bennett on 2019-10-01 15:40:25 EDT ---

Feels too late for 4.2.0. Let's fix this in 4.2.1.

Comment 4 Jon Uriarte 2019-10-25 12:02:42 UTC
Verified on OCP 4.2.0-0.nightly-2019-10-25-021846 build on top of OSP 13 2019-10-01.1 puddle.

release image: registry.svc.ci.openshift.org/ocp/release@sha256:8f97aa21e1c0b2815ec7c86e4138362940a5dcbc292840ab4d6d5b67fedb173f

K8s NP (test/e2e/network/network_policy.go) tests related to NP enforcement through services passed.

Comment 6 errata-xmlrpc 2019-10-30 04:44:56 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-2019:3151


Note You need to log in before you can comment on or make changes to this bug.