named-port bug fix and tests

[shireenf-ibm]

#405

bug(s) description:
1. the analyzer ignored netpol rules with named ports that didn't have a match in the dst pod's configuration
(for example: if an ingress netpol captures pod-a with ingress rule that contains a named-port port-a (TCP protocol) and the pod's specification does not has a containerPort/ Port with this name -- this rule was ignored, has no mention in the output)
- fix: now we will see an ingress conn to pod-a on: TCP port-a in the output

2. when converting named-port to number, the analyzer didn't compare netpol rule's protocol (which is accompanied with the port) to the protocol of the pod's container port which has same port-name.
   for example: if a pod has containerPort with name: newport and protocol: UDP port:90
   and a netpol capturing that pod with ingress rule: port: newport protocol:TCP
   we saw on the output an ingress connection TCP 90 which is not true since this is not the same port.
   • fix: : the port-name and protocol are considered when converting a named port; if protocols don't match we will see the port-name in the output (in the example: conn is TCP newport)

3. Peer2PeerConnection (Connection) assumed the ports will always contain a numbered interval only
- fix: : PortRange interface contains also a NamedPort option; (the connection on a protocol may either be numbered or named; depends if we succeeded to convert it by from the pod's configuration or not)

tests with examples of the above (with matched and unmatched named-ports) were added

[adisos]

#405

bug(s) description:

1. the analyzer ignored netpol rules with `named ports` that didn't have a match in the dst pod's configuration
   (for example: if an ingress netpol captures `pod-a`  with ingress rule that contains a named-port `port-a`  (TCP protocol) and the pod's specification does not has a containerPort/ Port with this name -- this rule was ignored, has no mention in the output)
   
   * **fix:** now we will see an  ingress conn to `pod-a` on: `TCP port-a` in the output

2. when converting named-port to number, the analyzer didn't compare netpol rule's protocol (which is accompanied with the port) to the protocol of the pod's container port which has same port-name.
   for example: if a pod has containerPort with `name: newport` and `protocol: UDP port:90`
   and a netpol capturing that pod with ingress rule: `port: newport protocol:TCP`
   we saw on the output an ingress connection `TCP 90` which is not true since this is not the same port.
   
   * **fix:** : the port-name and protocol are considered when converting a named port; if protocols don't match we will see the port-name in the output (in the example: conn is `TCP newport`)

3. `Peer2PeerConnection`  (`Connection`) assumed the ports will always contain a numbered interval only
   
   * **fix:** : `PortRange` interface contains also a `NamedPort` option; (the connection on a protocol may either be numbered or named; depends if we succeeded to convert it by from the pod's configuration or not)

tests with examples of the above (with matched and unmatched named-ports) were added

I agree with 2 , but not sure about 1 , whether it is an issue. (Does 3 follow from 1 ?)
As for 1 -- if a concrete Pod has no matching named port on the yaml config, can it accept traffic on such named port that the policy specifies?
(For exposure analysis it makes sense to specify named ports in the output, since we do not have the real pod configuration).

[adisos]

rename portRageArr to portRangeArr

[shireenf-ibm]

done

[shireenf-ibm]

#405
bug(s) description:

1. the analyzer ignored netpol rules with `named ports` that didn't have a match in the dst pod's configuration
   (for example: if an ingress netpol captures `pod-a`  with ingress rule that contains a named-port `port-a`  (TCP protocol) and the pod's specification does not has a containerPort/ Port with this name -- this rule was ignored, has no mention in the output)
   
   * **fix:** now we will see an  ingress conn to `pod-a` on: `TCP port-a` in the output

2. when converting named-port to number, the analyzer didn't compare netpol rule's protocol (which is accompanied with the port) to the protocol of the pod's container port which has same port-name.
   for example: if a pod has containerPort with `name: newport` and `protocol: UDP port:90`
   and a netpol capturing that pod with ingress rule: `port: newport protocol:TCP`
   we saw on the output an ingress connection `TCP 90` which is not true since this is not the same port.
   
   * **fix:** : the port-name and protocol are considered when converting a named port; if protocols don't match we will see the port-name in the output (in the example: conn is `TCP newport`)

3. `Peer2PeerConnection`  (`Connection`) assumed the ports will always contain a numbered interval only
   
   * **fix:** : `PortRange` interface contains also a `NamedPort` option; (the connection on a protocol may either be numbered or named; depends if we succeeded to convert it by from the pod's configuration or not)

tests with examples of the above (with matched and unmatched named-ports) were added

I agree with 2 , but not sure about 1 , whether it is an issue. (Does 3 follow from 1 ?) As for 1 -- if a concrete Pod has no matching named port on the yaml config, can it accept traffic on such named port that the policy specifies? (For exposure analysis it makes sense to specify named ports in the output, since we do not have the real pod configuration).

reverted 1 & 3

[shireenf-ibm]

• deleted tests that does not have fixed results (comparing to main).

remaining tests results fix :

• test: netpol_named_port_test

output with bug included following line: (UDP 8956 is a wrong convert of pod's namedPort: - name: newport containerPort: 8956 protocol: SCTP
helloworld/new-pod[Deployment] => helloworld/pod-a[Deployment] : UDP 8956
after fixing the bug this line will not be included sincepod-a configuration does not contain a newport: 8956 with UDP

• netpol_named_port_test_2:

output with bug would have following line:
helloworld/pod-a[Deployment] => helloworld/new-pod[Deployment] : SCTP 8956,9090,**UDP 9090**
after fixing bug the correct connection is:
helloworld/pod-a[Deployment] => helloworld/new-pod[Deployment] : SCTP 8956,9090
(since new-pod does not have a port named: newport: 9090 with protocol UDP`)

[adisos]

please add comment near each named port in the tests, if it is expected to be matched by network policy rule with named port or not.

also, do we need both tests? what is the difference between what they cover?
a comment with details about each test may help in the unit tests file.

[shireenf-ibm]

added comments to netpols files + connlist_test file.
although the tests cover same "issue"
(both tests contain a named-port with protocol that does not match the protocol in the pod's configuration (with same named-port)
and one test's netpol includes also a named-port that has no matching port name in the pod.)

the output of the tests differs,

• in one test since there is no matching port - we don't see any connection between the 2 pods in the connlist
• in the second tests, we see connection with the two ports that were successfully converted