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.