don't remove representative peers in any-namespace

[shireenf-ibm]

issue #236

sub task:

• • handling cases of empty nsSelector (any-namespace) with non-empty podSelector : don't refine its representative peer if there is a matching pod in a specific namespace

also: keep representative peer for the case of all pods within a certain namespace

[adisos]

added one question

[adisos]

does it differentiate between

namespaceSelector: {}
podSelector: {k: v}

(which is any namespace)

to

podSelector: {k: v}

(which is the network policy namespace)?

[adisos]

and what about

namespaceSelector: {k: v}
podSelector: {}

this creates exposure to all pods in a certain namespace..
does this require indication as exposure?
it's not as matching pod with certain labels..

do we have any example test capturing this case with current implementation?

[shireenf-ibm]

does it differentiate between

namespaceSelector: {}
podSelector: {k: v}

(which is any namespace)

to

podSelector: {k: v}

(which is the network policy namespace)?

yes, it does
examples:

1. tests/test_conn_with_pod_selector_in_any_ns with :

• from:
  - namespaceSelector: {}
  podSelector:
  matchLabels:
  role: monitoring

(output: test_outputs\connlist\exposure_test_conn_with_pod_selector_in_any_ns_connlist_output.dot.png)

2. tests/test_conn_with_only_pod_selector

• from:
  - podSelector:
  matchLabels:
  role: monitoring
  (output:test_outputs\connlist\exposure_test_conn_with_only_pod_selector_connlist_output.dot.png)

[shireenf-ibm]

and what about

namespaceSelector: {k: v}
podSelector: {}

this creates exposure to all pods in a certain namespace.. does this require indication as exposure? it's not as matching pod with certain labels..

do we have any example test capturing this case with current implementation?

we have following example:
test: tests\test_conn_to_all_pods_in_a_new_ns
with:

• from:
  - namespaceSelector:
  matchLabels:
  kubernetes.io/metadata.name: backend
  podSelector: {}

output: test_outputs\connlist\exposure_test_conn_to_all_pods_in_a_new_ns_connlist_output.dot.png

in this example the backend ns is not in the manifests and we have no real pods in this ns so we see an exposure to representative peers backend\[all pods].

if we had a real pod in the namespace backend : it would be a match and we won't see the exposure line.(like all cases where the podSelector was not used, if there is a pod in the namespace the it is a match)

[adisos]

in this example the backend ns is not in the manifests and we have no real pods in this ns

I would add another example where there is a real pod in the namespace backend

if we had a real pod in the namespace backend : it would be a match and we won't see the exposure line.

ok, the question is - should we consider changing this behavior (when the policy permits all pods in a real namespace)? if all pods in a namespace are permitted, it might be relevant as exposure info, even if there is a certain real pod in the namespace. (BTW there could be a real pod in that namespace on which there is a certain policy that blocks such a connection for this pod.. in such a case the connection to this pod is not in the report, nor the exposure to this namespace). [consider adding such an example as well]

[shireenf-ibm]

I meant to a policy that selects all pods in its namespace.. (let it be foo namespace) let's assume we do not have a pod in that namespace but another pod (bar/pod1) has exposure to this namespace (e.g. policy that permits egress to foo) the question is - do we consider such policy on a representative peer (namespace)? (for example, a policy that is a default deny for the foo namespace)

I will add an example to see the behavior and update

[shireenf-ibm]

added an example locally, the exposure analysis of bar still shows the line:
bar/workload-a[Deployment] => foo/[all pods] : All Connections
even that we have default-deny-in-foo for ingress

should fix the bug in this PR?

[adisos]

create new item and implement in a separate PR .
analysis should generate representative peers by also considering policies that capture them, and separate into sub-sections (sub-peers) that are having different connectivity by the policies (for example pods in ns with certain labels, and pods in ns without these labels).

[adisos]

if we had a real pod in the namespace backend : it would be a match and we won't see the exposure line.

ok, the question is - should we consider changing this behavior (when the policy permits all pods in a real namespace)? if all pods in a namespace are permitted, it might be relevant as exposure info, even if there is a certain real pod in the namespace.

I see, yes we can change this. our assumption was that if there is a rule selecting a namespace and there was a real pod in that namespace so the "developer" knows that connections are allowed to that namespace and didn't add it to the exposure lines. so by changing this we want to emphasize that conns with all pods in that namespace are allowed . ( however this will affect also tests with only namespaceSelector, where the namespace is real and there is a pod in it in the manifests )

(BTW there could be a real pod in that namespace on which there is a certain policy that blocks such a connection for this pod.. in such a case the connection to this pod is not in the report, nor the exposure to this namespace). [consider adding such an example as well]

I prefer to add such examples within the adding more complicated tests PR

ok, let's have this change in this PR , including adding the relevant examples , and mark by the example which has inaccurate output, a TODO comment, to make sure it is fixed in the next PR .

[shireenf-ibm]

done

[shireenf-ibm]

in this commit
added two examples of exposure to an existing namespace (having real pod in the ns)
with current approach:

• in first test test_conn_to_all_pods_in_an_existing_ns since we have a real pod in backend we don't see "all pods" exposure line
• in second test test_conn_to_new_pod_in_an_existing_ns I used specific podSelector and so we see it in the exposure report