This is maybe out of scope for this issue, and admittedly I'm still working on understanding Network Policies, but I'm struggling to understand the logic in Popeye on checking ingress/egress policies.

If we get to this branch of code:

I'm not sure the logic in checkIngresses / checkEgresses is wholly correct.

If we have a NetworkPolicy which targets the pod in question, and it has ingress rules, checkIngresses appears to want the ingress's from to point to the same pod.

Similarly for checkEgresses, it's wanting the egress's to to point to the same pod.

In other words, this seems to only pass when the NetworkPolicy says the pod can talk to itself.

@bpfoster For the initial issue, this is indeed a problem. Will fix on the next drop.
For the later, this code checks if a given pod is protected by a networkpolicy.

Fixes v0.21.5

I just had a similar thing come up when denying egress:

  · about-me/about-me-5d8f856785-pb7vx.............................................................😱
    😱 [POP-1204] Pod Egress is not secured by a network policy.

This is my NetworkPolicy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-egress
spec:
  podSelector:
    matchLabels:
      app: about-me
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - {}
  egress: []

I did verify that the policy works by looking at the drops in Cilium.

Am I missing something?

I hadn't revisited this. I too am still getting (at least consistently now!) false positives on networkpolicy linting (on latest popeye v0.21.5).

In my case, I get Pod Ingress is not secured by a network policy despite NetworkPolicies being present. checkIngresses() is still coming back with no matches so I still wonder about how that is being evaluated.
My Network Policies look like:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  labels:
    app.kubernetes.io/instance: my-instance
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: my-service
    app.kubernetes.io/version: 0.0.1
    helm.sh/chart: my-service-0.1.0
  name: my-networkpolicy
  namespace: my-namespace
spec:
  egress:
  - ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: my-namespace
  - ports:
    - port: 80
      protocol: TCP
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: my-namespace
    ports:
    - port: http
      protocol: TCP
  podSelector:
    matchLabels:
      app.kubernetes.io/instance: my-instance
      app.kubernetes.io/name: my-service
  policyTypes:
  - Ingress
  - Egress

For @siegy22 's example, playing around with some unit tests, changing egress to look like ingress removes the finding:

ingress:
  - {}
egress:
  - {}

But I frankly don't know if the result is the same?

@bpfoster Your example denies ingress and egress. My goal is to have any ingress and no egress.

Which is defined by:

ingress:
  - {}
egress: []

But popeye says there's no egress defined (which in theory is correct) but the effect is not the same as not defining it.

@derailed please see PR #367 - I think this will address the false positives @siegy22 and I are seeing, if I have not misunderstood something here.