Currently, the hackish way to detect cluster-external workloads is to check if we found a OwnerName/Type associated with the flow. If not, we may assume it is external. But it has some limits:

• local-loop addresses such as "10.0.0.2" are false-positives
• there could be other in-cluster IPs for which we're unable to find a match, but still, are in-cluster (e.g. some CNI-specific stuff; or deleted workloads)

Note that it can also be done as suggested in this task: NETOBSERV-629 - which would allow to mutualize progress on the other epic NETOBSERV-628

Bonus if we can also flag cluster gateways this way (for multi-clusters)

This feature allows to associate any IP subnet (CIDR) with a custom label, and/or use automatic labels based on known OpenShift subnets. These labels can be used to "flag" any IP / workload based on subnets, regardless if they are internal or external to the cluster. It allows, for instance, to flag a cluster-external workload, or web-service, that the user knows about, but that is unknown to FLP via the kube-enrichment.

The feature introduces 2 optional new fields in the Flows model: SrcSubnetLabel and DstSubnetLabel. To enable them, FlowCollector `spec.processor.subnetLabels` must be configured.

Default subnets that can be automatically detected, based on OpenShift configuration, are:

• Machines network (label = "Machines")
• Pods network (label = "Pods")
• Services network (label = "Services")

Note that, while there is an overlap with the existing kube-enrichment for these labels (we already enrich Node, Pod or Service resources so we know their type), this feature also allows to close a gap with IPs that do belong to the machine/pod/service subnets but that kube-enrichment fails to recognize, for various reasons (e.g. a machine network IP set up by OVN but not identified as the main node IP would be seen as "unknown" without this feature)

As a consequence, without this feature it is very hard / impossible to accurately identify cluster-external traffic, ie. traffic with a peer that is neither a Pod, or Service nor a Node. With this feature it finally becomes possible.