When NP policies are being used with podSelectors, for instance: ingress: - from: - podSelector: matchLabels: run: demo If a service points to pods where the above defined policy applies, its sg rules should be updated when pods with label 'run: demo' are created/deleted so that their associated IPs are either accepted or rejected. Right now, if there is a pod (demo-1) with label 'run: demo' belonging to a deployment (demo), and that pod is killed, a new pod gets created by the deployment (demo-2), however, the svc sg rules keep accepting demo-1 IP instead of demo-2. Similarly for scaling actions. In addition, if this is used together with pools, it may lead to a security breach as other pod without the right label could get the IP belonging to demo-1 pod, and access the svc while it should not be able to do so.
Previously, when a Network Policy was enforced on pods pointed by a Service and a pod matching the Network Policy rules specification got created, only the Pods security groups got updated, when the Load Balancer security groups should also be updated. Now, whenever a pod event is triggered and the pod matches the Network Policy rule, both the set of pods pointed by the Network Policy and the Load Balancer get the security groups updated. Furthermore, it's also ensured that regardless of the order of Kubernetes resource creation the Load Balancer security group is updated accordingly.
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/RHEA-2019:2811