Beheer, uitval en herstel van de keten

Platformbeheer is eindverantwoordelijk voor de keten; het ontwikkelteam bouwt haar en draagt haar over. Applicatieteams zijn eigenaar van hun software en van de toelatingen die zij aanvragen. GitLab en zijn pakketregistry blijven bij de leverende RWS-dienst.

Beheer van containerregistry, ondertekenvoorziening en bouwcluster loopt via de toegangsvoorziening met meerfactoraanmelding en de beheerwerkplek, als opgenomen sessie. Niemand heeft persoonlijk schrijfrecht in een vrijgegeven ruimte. De lokale beheerders van Quay, Trusted Artifact Signer en het bouwcluster zijn noodaccounts in de kluis.

Iedere technische identiteit van de keten heeft één taak, een eigenaar en rechten alleen op haar eigen ruimte of sleutel, en geldt per cel; alleen de ondertekening is vlootbreed. Het platform heeft een Chains-besturing (alleen de bouwsleutel), een toelatingsidentiteit (alleen de toelatingssleutel, de quarantaine voor derden en de ruimte derden), een overzetidentiteit (lezen in de quarantaine, schrijven in vrijgegeven), een spiegelidentiteit, per cel een replicatie-identiteit en per cluster een leesrobot. Hun toegangsbewijzen zijn kortlevend en gefedereerd; alleen de leesrobot heeft een beheerd langlevend geheim.

De keten kent deze vertrouwensgrenzen: tussen teams (naamruimte, identiteit en geheimenpad), tussen bouwtaken en platform (EgressFirewall en netwerkbeleid per naamruimte), tussen quarantaine en vrijgave (rechten en twee controles), tussen de cellen (replicatie met controle) en tussen vloot en cel, die alleen de vertrouwensbasis delen.

Alle inrichting van de keten is code: sjabloon en register in de opslagplaats Catalogus; toelatingsbeleid, vertrouwensbasis en de lijsten van licenties en bronnen in de opslagplaats Beleid; spiegelset, ruimtes en robotaccounts in de opslagplaats Platform. Ook de bewaarregel en de clusterdefinitie van het bouwcluster staan als code in versiebeheer. Een afwijking wordt gemeld en teruggezet, en een persoon handelt alleen bij de beoordeling van een wijzigingsvoorstel en bij het toelatingsbesluit over software van derden.

Beleidsobjecten, voorvoegsels, namen en capaciteit van de keten worden uitgewerkt in de instellingen en de het detailontwerp van platformbeheer; hostnamen en adressen staan alleen in dat detailontwerp en in de inventaris.

Binnen de cel is het rek het foutdomein: werkers van het bouwcluster en exemplaren van de Policy Controller staan in verschillende rekken. Per onderdeel liggen plaatsing, gedrag bij uitval en herstel vast.

Valt vanaf groeipadstap 2 beheercel 1 uit, dan start en schaalt cel 2 met haar kopie van de vrijgegeven inhoud, maar staan bouw en ondertekening stil. Na herstel van vlootbeheer en versiebeheer in cel 2 wordt het bouwcluster daar uit code opgebouwd, met nieuwe sleutels; de replicatie keert om en cel 2 spiegelt zelf.

Is het bouwcluster, een sleutel of de ondertekenvoorziening aangetast, dan zijn handtekeningen uit de getroffen periode niet te vertrouwen. Platformbeheer stopt dan met het SOC de pijplijnen, trekt het vertrouwen in, blokkeert de inhoudskenmerken en laat opnieuw bouwen en ondertekenen.

De keten is uit code op te bouwen, en haar gegevens hebben een back-up volgens het back-upschema. Het bouwcluster heeft geen eigen gegevens: het wordt uit code via het leverpad herbouwd, met naamruimten en identiteiten uit de opslagplaats Platform.

De herstelkern bevat de beelden van de laatste vrijgave met hun handtekeningen en attesten, en via de opslagplaats Beleid de vertrouwensbasis. Zo controleert een herbouwde cel zonder vlootcluster.

Iedere meetwaarde van de keten heeft een drempel, een actie en een ontvanger; de drempels liggen vóór de harde grens.

Het gebruik van bouwcluster en ruimtes wordt per team gemeten en gerapporteerd, en de capaciteit van één werker van het bouwcluster blijft reserve voor uitval. Voor wat de keten zelf verbruikt, gelden deze grenzen.

Een nieuwe versie wacht alleen op de beoordeling van het wijzigingsvoorstel, niet op een beheerdomein; de maatstaven voor softwarelevering en softwareketen zijn de norm, en kritieke kwetsbaarheden volgen de spoedroute. Groeipadstap 3 vraagt extra werkers en objectopslag voor meer teams en voor de beelden van AI-toepassingen; locaties krijgen alleen de versies die zij nodig hebben en bewaren wat zij voor herstel nodig hebben.

Audit- en beveiligingslogboeken van de keten gaan rechtstreeks naar het SOC, met bevestigde ontvangst en een kopie buiten het bereik van platformbeheer. De containerregistry stuurt haar gebruikslogboeken via haar logkoppeling naar de SIEM; pijplijnen, ondertekenende besturing en ondertekenvoorziening sturen hun gebeurtenissen via de logverzamelaar. Logboeken bevatten geen tokens of sleutels.

Alle eindpunten van de keten sluiten zelf TLS af, ook het ontvangstpunt van de webhooks, met certificaten uit de interne PKI van ten hoogste 90 dagen. Beelden, handtekeningen en databases staan versleuteld op het opslagcluster, en ondertekeningssleutels verlaten de transit-engine van het geheimenbeheer niet.

Voor de keten zijn deze draaiboeken vereist, elk met een eigenaar en een beproeving. Ze staan in de opslagplaats Draaiboeken; platformbeheer voert ze vóór de overdracht zelf uit.

Iedere eigenschap van de keten heeft een draaiboek en een beproeving met slaagcriterium, ook negatief: wat verboden is, wordt aantoonbaar geweigerd.

Bij de acceptatie van de keten wordt, samen met het SOC, het volgende aangetoond; iedere negatieve proef afzonderlijk bij de toelatingscontrole en bij het ophalen op het knooppunt.

De keten doorloopt deze fasen, elk met een voorwaarde voor de volgende.

Bij de opbouw komen eerst de containerregistry en de transit-engine, dan het vlootcluster met de ondertekenvoorziening en de vertrouwensbasis op ieder cluster, dan het bouwcluster en de pijplijnen, en als laatste de toelatingscontrole, eerst op melden. Voordat de keten start, zijn de tijdelijke registry en het tijdelijke versiebeheer van de opbouw uitgeschakeld en werken containerregistry, geheimenbeheer en toegang.