Intermediate

Het eerste cluster dat ik echt in productie draaide had precies één permissiemodel: alles was cluster-admin. Mijn CI pipeline, mijn monitoring stack, het kleine webhook-ontvangertje dat ik op een middag in elkaar zette. Allemaal konden ze elk secret lezen, elke deployment verwijderen en elke namespace aanraken. Het werkte prima, tot ik begon na te denken over wat er gebeurt als één van die pods wordt overgenomen. Kubernetes RBAC (Role-Based Access Control) beantwoordt één vraag: wie mag wat doen met welke resources? Het standaardantwoord op de meeste clusters is “iedereen kan alles doen,” en dat antwoord wordt stilletjes je grootste aansprakelijkheid. ...

De eerste keer dat ik kubectl get secret myapp -o yaml draaide en de waarde base64-decodeerde, zakte mijn maag. Daar stond mijn database-wachtwoord, gewoon in etcd, leesbaar voor iedereen die met de juiste RBAC bij de API kon. Kubernetes Secrets zijn geen secrets. Het is base64-gecodeerde platte tekst met een mooie naam. Dat is de default, en het is precies het ding waar niemand je op dag één voor waarschuwt. ...

Een base image pullen, je code erin kopiëren, naar productie pushen. Die lus draaien de meesten van ons op de automatische piloot. Het stuk waar niemand naar kijkt is de base image zelf, die stilletjes een paar honderd packages meesleept die je nooit gekozen hebt. Eén ervan kan een bekende CVE dragen, en je zou er geen flauw idee van hebben. Dat zit me dwars. Ik draai niet graag dingen die ik niet kan inspecteren, en een container image die je niet gescand hebt is precies dat: een black box die je vertrouwt omdat naar binnen kijken te veel moeite leek. ...

Stel je eerst de eindsituatie voor. Je merget een branch naar main, loopt weg om koffie te halen, en tegen de tijd dat je terug bent heeft het project een nieuwe versie-tag, een verse changelog-entry, en een GitLab release met notes die uit je commits zijn geschreven. Niemand besloot “is dit 1.4.0 of 1.3.5?” omdat niemand dat hoefde. Het versienummer rolde uit het werk zelf. Daar wil ik in deze post naartoe. Ik draai een self-hosted GitLab en ik wil niet dat versioning iets is waar ik over nadenk. Een versienummer dat iemand met de hand kiest is een klein black box: het hangt ervan af of die persoon de regels onthield, oplette, en het met iedereen eens was over wat als een breaking change telt. Ik heb liever dat het nummer een consequentie van de commits is, iets dat ik kan inspecteren en reproduceren. ...

Lange tijd draaide mijn CI op de servers van iemand anders. Push code, wacht op een hosted runner, kijk hoe de minuten aftikken tegen een maandelijks quotum, hoop dat de provider de regels niet verandert volgend kwartaal. Het werkte, tot ik me begon af te vragen waar mijn broncode eigenlijk stond terwijl hij gebouwd werd, en wie er nog meer bij kon. Dus haalde ik GitLab in huis. Ik draai hem nu self-hosted, op eigen hardware, naast de clusters waarnaar hij deployt. Dat is soevereiniteit toegepast op CI/CD: mijn code, mijn builds, mijn artifacts, geen vendor die prijzen kan veranderen, een feature kan deprecaten waar ik van afhankelijk ben, of mijn repositories kan lezen zonder dat ik het weet. ...