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 iedereen die netwerken beheert heeft het wel eens gezien: Twee hosts die hetzelfde IP(v4) adres proberen te gebruiken. Dit zorgt over het algemeen voor veel hilariteit en weinig productiviteit.

Op systemen die “NetworkManager” gebruiken kan er een simpele veiligheidsmaatregel worden aangezet: een ARP request voor het gewenste IPv4 adres voordat deze geactiveerd wordt. Is het adres in gebruik, dan wordt de verbinding niet geactiveerd.

Op RHEL9 en ouder staat deze test standaard uit, op RHEL10 en Fedora41 staat deze test standaard aan.

Om het nieuwe jaar goed te beginnen, en misschien wat te helpen met goede voornemens, laat Wander in deze video het (stokoude) commandline tooltje fortune zien. Een kleine applicatie die een willekeurige quote uit een (willekeurige) gekozen lijst aan quotes laat zien.

Spoiler Alert: Deze video bevat wat hints voor de Kerst Puzzel

Zoals elk jaar hebben we ook dit jaar weer de traditionele Kerst Puzzel voor jullie.

Dit jaar is de opgave simpel:

Je bent ingebroken op het datacenter van de Kerstman (iets met jezelf uit de database van stoute mensen willen verwijderen). Je hebt nu een shell op de authorative nameserver voor het .santa domein, en je bent op zoek naar de hostnaam (FQDN) en omschrijving van de server waar de database voor de stouterds op wordt bewaard.

Zoals elk jaar hebben we ook dit jaar weer de traditionele Kerst Puzzel voor jullie.

Dit jaar is de opgave simpel:

Je bent ingebroken op het datacenter van de Kerstman (iets met jezelf uit de database van stoute mensen willen verwijderen). Je hebt nu een shell op de authorative nameserver voor het .santa domein, en je bent op zoek naar de hostnaam (FQDN) en omschrijving van de server waar de database voor de stouterds op wordt bewaard.

In het verleden hebben we hier al vaker gekeken naar Podman Quadlets, een makkelijke manier om containers als systemd services te draaien. We hebben gekeken naar het maken van container units, en naar het templaten van comtainer units. Maar wat we nog niet gedaan hebben is het kijken naar container image builds met quadlets.

In een Containerfile levert elk RUN commando een aparte “layer” op in het resulterende image. Wanneer je in een latere layer data uit een eerdere layer verwijdert blijft deze data dus wel in je container image zitten, je ziet het alleen niet meer.

Een veel voorkomend voorbeeld hiervan is bijvoorbeeld de gecachete metadata van je package manager.

Wanneer je kustomize gebruikt om met Overlays de lifecycle-fases van je applicatie te beheren dan ga je vroeger dan later een keer de vragen stellen hoe je promoties van images (en Bases) tussen deze fases kunt automatiseren. Met de hand references en image transformers doorzetten is meestal geen optie vanwege de kans op fouten, en het willen automatiseren van de promotie pipelines.

Nu zijn er bestaande oplossingen met tools als Renovate die dit (gedeeltelijk) voor je kunnen oplossen, maar die hebben vaak wat meer infrastructuur nodig. Als je deze tools nog niet gebruikt dan zou je zelf wat scriptjes kunnen schrijven, maar nu heb je nog iets extras om te beheren en bij te houden.

Één van de nieuwe features in RHEL9.5 is de mogelijkheid om in Cockpit, de grafische management console van RHEL, bestanden te beheren alsof je in een grafische file-manager werkt.