Handle nsfilter/fromsource filter from a common func #532
Conversation
Signed-off-by: Eswar Rajan Subramanian <eswar@accuknox.com>
Signed-off-by: Eswar Rajan Subramanian <eswar@accuknox.com>
|
@nyrahul @wazir-ahmed |
Signed-off-by: Eswar Rajan Subramanian <eswar@accuknox.com>
| if IgnoreLogFromRelayWithNamespace(nsFilter, nsNotFilter, flow.Destination.Namespace) { | ||
| continue | ||
| } | ||
|
|
||
| if IgnoreLogFromRelayWithNamespace(nsFilter, nsNotFilter, flow.Source.Namespace) { | ||
| continue | ||
| } | ||
|
|
There was a problem hiding this comment.
@seswarrajan @nyrahul
Sorry for reporting this late. In case of network policy, we should not filter the flows (as soon as we receive it). We should only filter the "policy" (after we convert the flows to a policy).
The reason for this is.. Consider the following example.
1. Flow | default/frontend --> kube-system/kube-dns
2. Flow | default/frontend --> default/checkout
Without any filtering logic, this would create four policies.
1. namespace: default, spec: frontend --(egress)--> kube-dns @ port: udp/53
2. namespace: kube-system, spec: kube-dns <--(ingress)-- frontend @ port udp/53
3. namespace: default, spec: frontend --(egress)--> checkout @ port: tcp/7070
4. namespace: default, spec: checkout <--(ingress)-- frontend @ port tcp/7070
In the namespace filters, even if user says !kube-system, we should create policy-1 because it a policy for pod in default namespace. Without applying policy-1, if we only apply policy-3, then that will break frontend-pod because it will fail to resolve DNS to any service in the cluster.
There was a problem hiding this comment.
Thanks for the update @wazir-ahmed But I need to ignore those logs for observability. I will see how it can be handled in observability engine instead of cilium hubble log collection
This reverts commit 24ed1cf.
This reverts commit 24ed1cf.
Signed-off-by: Eswar Rajan Subramanian eswar@accuknox.com