In sommige omgevingen krijgen OpenShift beheerders te horen dat (specifieke) workloads gelimiteerd moeten worden in wat ze (buiten het cluster) kunnen aanspreken aan externe diensten en hosts. Nu kun je dit met standaard NetworkPolicy objecten oplossen, maar aangezien afnemers over het algemeenNetworkPolicy objecten in hun eigen namespaces mogen editen is dit niet de meest robuuste oplossing.

Je zou ook kunnen gaan werken met EgressIP objecten, en verkeer van die IP adressen buiten het cluster laten filteren, maar dan kom je al snel in een wereld waar je honderden extra IPv4 adressen nodig hebt.

Je zou ook met AdminNetworkPolicy objecten bezig kunnen gaan, maar deze zijn nog redelijk nieuw, en werken nog niet buiten OpenShift.

Gelukkig is er ook nog een vierde optie voor gebruikers van het OVN-Kubernetes SDN: EgressFirewalls

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.

Om verkeer van buiten een Kubernetes/OpenShift cluster in te krijgen heb je waarschijnlijk een LoadBalancer nodig, om bijvoorbeeld je Ingress te ontsluiten, of om services rechtstreeks aan te bieden.

Wanneer je in een cloud omgeving draait biedt je provider waarschijnlijk loadbalancers aan die rechtstreeks door je cluster aangestuurd kunnen worden, maar wanneer je op Baremetal draait, of op LibVirt, of op VMWare, dan missen deze opties.

Op een Kubernetes cluster (dus ook OpenShift) kun je je pods bereikbaar maken met Service objecten. Deze objecten kunnen verschillende types hebben, headless, ClusterIP, NodePort, LoadBalancer, en ExternalName.