Wanneer je met Podman een container of pod maakt wordt deze als je niks anders opgeeft aan het standaard “podman” network gekoppeld. Als je meer controle wilt, bijvoorbeeld omdat je een gelaagde applicatie in meerdere containers of pods draait, dan mag je ook zelf extra netwerken aanmaken en bepalen welke containers/pods aan welke netwerken gekoppeld zitten.

Praktisch elke Kubernetes/OpenShift beheerder kent het principe van de NetworkPolicy, objecten binnen een namespace die bepalen welk verkeer van en naar je pods is toegestaan binnen die namespace. Om hier gezonde defaults voor af te dwingen hebben de meeste (multi-tenant) clusters ook al maatregelen, zoals DefaultProjectRequestTemplates of Kyverno “generate” regels, die een set “standaard” NetworkPolicies in elke namespace neerzetten. Het probleem dat nu ontstaat is dat als tenants hun eigen NetworkPolicies moeten kunnen maken, om de toegang binnen hun applicaties fijnschalig te kunnen regelen, ze ook rechten moeten hebben om de defaults aan te passen of te verwijderen. Nu hoeft dat geen probleem te zijn, maar als teams minder voorzichtig of ervaren zijn kan dat al snel leiden tot support calls omdat de OpenShift ingress pods bijvoorbeeld niet meer bij hun applicatie mogen, en hun Routes zijn stukgegaan. Gelukkig hebben in OpenShift 4.14 NetworkPolicies een uitbreiding gehad, die in 4.16 GA gegaan is en dus ondersteund gebruikt kan worden: AdminNetworkPolicies.

OpenShift Network Observability Operator In recente versies van OpenShift kun je de “Network Observability Operator” installeren om een beter inzicht te krijgen in de netwerk flows tussen de verschillende componenten/pods/services/etc op je cluster, als ook het netwerk verkeer dat je cluster verlaat. Deze inzichten kunnen dan gebruikt worden voor verschillende zaken; Het doorberekenen van netwerk gebruik, optimalisatie van traffic-flow tussen de componenten van een micro service, of zelfs het detecteren van “ongebruikelijk” verkeer in een applicatie.