Bouwen op het bouwcluster

Het bouwcluster bouw-prd-c1-01 is een gehost cluster in cel 1 met drie virtuele werkers in drie rekken, zodat het uitval van één werker draagt. Het staat, net als het portaalcluster, in het routeringsdomein platform (vrf-platform), met werkers en ingang op een eigen segment uit VLAN 700–709 (L2-VNI 10700–10709) en een /26 uit de platformreeks; de adressen komen via DHCP-doorgifte van de gateway naar Infoblox.

Ieder team krijgt op het bouwcluster een eigen naamruimte met een quotum; een bouwtaak ziet de taken, geheimen en beelden van andere teams niet. Iedere bouwtaak draait als tijdelijke container in een schone omgeving, zonder toegang tot het knooppunt of andere naamruimten. De platformnaamruimten toelating en overzet zijn niet toegankelijk voor teams, en een team meldt zich niet aan op het bouwcluster.

Bouwtaken gebruiken het beperkte bouwprofiel dat OpenShift Pipelines voor bouwen levert. Dat profiel is ruimer dan het striktste profiel voor containers en geldt alleen op het bouwcluster, als vastgelegde uitzondering op de regel dat containers zonder verhoogde rechten draaien.

Het bouwcluster bereikt alleen de opslagplaatsen met broncode, de pakketspiegel, de containerregistry, de ondertekenvoorziening, het geheimenbeheer voor de eigen geheimen van de bouw en de andere vastgelegde bestemmingen; geen afnemerszone en geen platformcluster. Bibliotheken komen alleen uit de pakketspiegel. Omdat binnen het routeringsdomein platform geen firewall bouwtaken van basisdiensten scheidt, begrenzen EgressFirewall en netwerkbeleid het uitgaande verkeer per naamruimte; de proxy laat alleen toegestane bronnen door.

De softwarelevering gebruikt deze verbindingen; alle eindpunten sluiten zelf TLS af.

De dynamische test vóór de vrijgave voor reguliere productie loopt vanuit de naamruimte van het team op het bouwcluster naar het virtuele adres van het cluster voor ontwikkelen en beproeven op de externe verkeersverdeling (443), dat doorgeeft naar de ingang van dat cluster; niet rechtstreeks naar de afnemerszone.

Het pijplijnsjabloon heeft negen vaste stappen. Teams kiezen alleen de bouwmethode en hun eigen tests; de controle-, ondertekenings- en herkomststappen kunnen zij niet weglaten of wijzigen.

Het sjabloon verschijnt als genummerde, onveranderbare versie onder een versielabel (v1, v2, …) in de opslagplaats Catalogus; het platform bestuurt de pijplijn en laat alleen gepubliceerde versies toe. Een team legt in zijn eigen opslagplaats vast welke versie het gebruikt. Na publicatie van een opvolger blijft een versie ten hoogste 90 dagen bruikbaar, en een versie met een beveiligingsfout wordt direct ingetrokken en blokkeert dan al bij het ophalen.

Iedere vastlegging of ieder wijzigingsvoorstel start de pijplijn vanuit het versiebeheer, met een kortlevend alleen-lezen token voor die opslagplaats. Voor toepassingen stuurt GitLab een webhook via de externe verkeersverdeling en staat de PipelineRun met Pipelines as Code in de opslagplaats van het team. Voor platformsoftware start een Tekton-trigger op een webhook van Forgejo, omdat de Forgejo-koppeling van Pipelines as Code een Technology Preview is.

De taken git-clone en buildah komen via de cluster resolver uit de naamruimte openshift-pipelines; voor geheimencontrole, onderdelenlijst (syft) en de controle met roxctl zijn er eigen taken. De versies van syft en skopeo liggen vast in de taak van het sjabloon.

Bouwtaken en basisbeelden komen uit de vrijgegeven ruimte van de eigen containerregistry, bibliotheken alleen langs een uitgaande route met een lijst van toegestane bronnen. Omdat een toegestane bron iets zegt over de herkomst en niet over de inhoud, staat iedere gebruikte bibliotheek in de onderdelenlijst en wordt zij gescand.

Krijgt een basisbeeld of bibliotheek een beveiligingsupdate, dan herbouwt de pijplijn automatisch de software die volgens de onderdelenlijsten dat onderdeel bevat, en levert zij een nieuwe versie langs dezelfde stappen. De uitrol naar productie blijft een beoordeeld wijzigingsvoorstel.

Teams ontwikkelen volgens de regels voor veilig programmeren, gebaseerd op de OWASP-richtlijnen en vastgesteld door de CISO-functie; ze staan in de opslagplaats Platform. De pijplijn dwingt de technische controles af: statische code-analyse en analyse van afhankelijkheden in het sjabloon, en een dynamische beveiligingstest vóór de vrijgave voor reguliere productie. Een van buiten bereikbare toepassing krijgt ook vóór de vrijgave voor productie en daarna jaarlijks een dynamische beveiligingstest.

Veilig programmeren is verplicht voor alle software die op het platform draait, en alle software doorloopt een ontwikkelcyclus met beveiligingstests: statische analyse, een dynamische test en analyse van de samenstelling en afhankelijkheden.

Ieder team heeft een eigen pijplijnidentiteit (een serviceaccount, vanaf groeipadstap 2 met een SPIFFE-identiteit) en een gefedereerd robotaccount dat alleen in de eigen quarantaine schrijft. Met het taaktoken leest de pijplijn de broncode en dient zij het wijzigingsvoorstel in; wat dat token mag, legt het team in GitLab vast. Het platform zelf heeft geen toegang tot de opslagplaatsen van teams.

Pijplijnen gebruiken alleen kortlevende toegangsbewijzen van ten hoogste 15 minuten per stap, via federatie met de pijplijnidentiteit: aanmelding bij het geheimenbeheer met de Kubernetes-identiteit, een gefedereerd robotaccount in Quay, het taaktoken in GitLab en een SSH-certificaat uit het geheimenbeheer in Forgejo. Er zijn geen robotaccounts of projecttokens per team in de pijplijn. Ook toelating, overzet, spiegel en replicatie schrijven met gefedereerde robotaccounts.

Een team kan zelf een sjabloonversie kiezen, bouwmethode en tests bepalen, het wijzigingsvoorstel met het nieuwe inhoudskenmerk na beoordeling samenvoegen, een toelating aanvragen en zijn rapporten inzien. Een team kan niet: stappen uit het sjabloon weglaten, ondertekenen, in een vrijgegeven ruimte schrijven, zich aanmelden op het bouwcluster, software van buiten de containerregistry starten of de toelatingscontrole uitschakelen.

De softwarelevering biedt deze interfaces, elk met een eigen isolatie en grens.