Egress to a Service records the Service port, not the endpoint port the CNI enforces on

[darkweaver87]

Description

For egress to a Service whose port differs from its targetPort, the generated NetworkPolicy opens the Service port. CNIs that enforce on the resolved endpoint match the targetPort, so the rule never matches and the traffic is denied once a default-deny is in place.

Environment

OS: Amazon Linux 2023, kernel 6.12 (arm64)
Version: kubescape-operator chart 1.40.3, node-agent v0.3.215, storage v0.0.297
CNI: AWS VPC CNI 1.23, NetworkPolicy enforcement in standard mode

Steps To Reproduce

1. Expose a workload with a Service using port: 80, targetPort: 8080
2. Have a client call it through the Service, and wait for the learning window
3. kubectl get generatednetworkpolicies -n <ns> <client> -o yaml
4. Apply the generated policy together with a default-deny in the client's namespace

Expected behavior

The rule opens 8080, the port the CNI enforces on:

egress:
  - to: [{podSelector: {matchLabels: {app.kubernetes.io/name: api}}}]
    ports: [{port: 8080, protocol: TCP}]

Actual Behavior

The rule opens 80, and the connection is denied once default-deny is in place:

egress:
  - to: [{podSelector: {matchLabels: {app.kubernetes.io/name: api}}}]
    ports: [{port: 80, protocol: TCP}]

Additional context

The agent observes the connection to the ClusterIP before DNAT, while enforcement happens on the endpoint after it. This one fails closed and the rule looks correct on review, so it is the most damaging of the behaviours we hit: generated policies cannot be applied unedited on such CNIs, and every port != targetPort Service in a cluster is affected. Resolving the Service to its endpoint port at generation time would fix it.