Software komt langs drie routes binnen en is pas bruikbaar na vrijgave in de containerregistry van de cel: eigen software via de bouw, software van derden via de toelatingsroute en platformsoftware via de gecontroleerde spiegel. Quarantaine, rechten per ruimte en doorzetten op inhoudskenmerk houden die vrijgave controleerbaar.
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
De softwarelevering bepaalt langs welke weg software het platform binnenkomt en wanneer zij op een cluster mag starten.
Er zijn drie aanvoerroutes: de bouw van eigen software, de toelatingsroute voor software van derden en de gecontroleerde
spiegel voor platformsoftware van de leverancier. Alle routes eindigen in dezelfde vrijgave in de containerregistry van
de cel, na quarantaine, scan en ondertekening.
Dit onderwerp legt vast hoe die vrijgave werkt: de ruimtes van de containerregistry en wie erin schrijft, het doorzetten
op inhoudskenmerk, de bewaartermijnen, het register van toegelaten software, de spiegel en de replicatie tussen de
cellen.
Waarom zo
Eén vrijgave voor alle routes geeft de clusters één regel: zonder geldige handtekening van het platform start er niets.
Doordat bouwen, vrijgeven en uitvoeren bij verschillende identiteiten liggen, kan een gecompromitteerde bouw of een team
zijn eigen resultaat niet tot productie toelaten. Doorzetten op inhoudskenmerk zorgt dat productie precies draait wat
eerder is beproefd.
De ruimtes, de termijnen en de wijze van replicatie zijn een voorstel. Ze volgen uit de keuze om iedere cel zelfstandig
te laten werken en herstellen, zonder gedeelde database tussen de cellen.
Software komt langs drie routes binnen: eigen software via de bouwpijplijn op het bouwcluster, software van derden die RWS niet zelf herbouwt via de toelatingsroute, en platformsoftware van de leverancier via de gecontroleerde spiegel. Alle drie eindigen in één vrijgave in de eigen containerregistry: pas na quarantaine, scan en ondertekening met attestatie mag software op een cluster starten, ook als RWS haar zelf heeft gebouwd.
Toelichting
Voor de clusters maakt de route daardoor niet uit: zij eisen een geldige handtekening van het platform, met als enige uitzondering de handtekening van de leverancier op platformsoftware uit de spiegel. De attestatie bij een beeld noemt de route en de controles: de herkomstverklaring van de bouw, het toelatingsattest of het spiegelverslag. Afgewezen: alle software zelf herbouwen, wat voor kant-en-klare software onwerkbaar is, of beelden per stuk als uitzondering toelaten, wat de controle ondergraaft. Herbouwen blijft de voorkeur waar de broncode beschikbaar is.
Per aanvoerroute liggen vast wat erlangs binnenkomt, hoe het platform vrijgeeft en waar bron en registratie staan.
Route
Wat
Hoe het platform vrijgeeft
Bron en registratie
Eigen software
Toepassingen van applicatieteams en platformsoftware van het ontwikkelteam
Bouwpijplijn op het bouwcluster volgens het vaste pijplijnsjabloon
Broncode in het RWS-brede versiebeheer (toepassingen) of in het versiebeheer van het platform (platformsoftware); het sjabloon in de opslagplaats Catalogus
Software van derden
Kant-en-klare containerbeelden, pakketten en configuratiesjablonen van leveranciers en opensourceprojecten
Toelatingsroute: quarantaine, controle van controlesom en eventuele handtekening van de leverancier, scan, toelatingshandtekening van het platform en registratie in het transparantielogboek; daarna vrijgave naar de ruimte voor software van derden
Register van toegelaten software in de opslagplaats Catalogus, met eigenaar, bron, versie, controlesom, of de leverancier heeft ondertekend, toelatingsbesluit en einddatum
Platformsoftware van de leverancier
Clusterversies, operators en installatiebestanden van de platformleverancier
Gecontroleerde spiegel: handtekening van de leverancier gecontroleerd bij spiegelen en ophalen, in de vorm waarin hij ondertekent (per release of per beeld); uitgerold door het vlootbeheer, eerst in de proefgroep
Spiegelverslag per versie met bron, versie, controlesom en uitkomst van de handtekeningcontrole; versies in de opslagplaats Platform
Toelichting
Het RWS-brede versiebeheer is GitLab; het versiebeheer van het platform is Forgejo.
Eigen software gaat in vijf overdrachten van bron naar toelating. Een mislukte stap laat niets vrij, en het taakresultaat met het inhoudskenmerk moet aantoonbaar horen bij het beeld dat in de quarantaine staat.
Van
Naar
Wat er gebeurt
Bron
Bouwcluster
De pijplijn controleert de ondertekende revisie, zoekt naar geheimen en voert code-analyse en tests uit
Bouwcluster
Quarantaine
De bouw maakt één beeld en legt inhoudskenmerk, scan en onderdelenlijst in CycloneDX vast
Chains-besturing
Ondertekenvoorziening
Tekent beeld en herkomst en registreert beide in het transparantielogboek Rekor
Overzetidentiteit van het platform
Vrijgegeven ruimte
Controleert handtekening én registratie en zet precies dezelfde inhoud over
Doelcluster
Toelatingscontrole
Controleert beleid, handtekening en inhoudskenmerk vóór gebruik
Een beveiligingsupdate van een basisbeeld, een bibliotheek of een leveranciersversie is een nieuwe versie langs de eigen aanvoerroute, nooit een wijziging ter plekke. Een nieuwe versie van software van derden doorloopt opnieuw de toelatingsroute.
Uit de quarantaine wordt niets uitgerold. Een team schrijft alleen in zijn eigen quarantaineruimte. Alleen identiteiten van het platform, buiten de naamruimten van teams, tekenen en schrijven in de ruimtes voor vrijgegeven software, software van derden en de spiegel; eigen en toegelaten software zetten zij pas over na controle van handtekening en registratie. Clusters lezen alleen vrijgegeven inhoud.
Toelichting
Geen teamnaamruimte heeft een ondertekeningssleutel of schrijfrecht in een vrijgegeven ruimte. Zo kan een bouwtaak haar eigen resultaat niet zonder controle tot productie toelaten. De rechten in Quay en de toets Toelatingscontrole van software tonen het aan.
Van ontwikkelen tot productie wordt steeds hetzelfde inhoudskenmerk vrijgegeven, niet een versielabel dat kan veranderen, en opnieuw bouwen voor een volgende omgeving is niet toegestaan. Versielabels zijn onveranderbaar. Zo draait in productie precies het beeld dat in de vorige omgeving is beproefd.
Toelichting
Het inhoudskenmerk is de koppelsleutel voor scan, onderdelenlijst, attest, handtekening, promotie en inventaris. Het onveranderbaarheidsbeleid van de containerregistry en de toets Herleidbaarheid van software tonen het aan.
Iedere containerregistry heeft vier ruimtes, als organisaties van Quay met parallelle voorvoegsels: quarantaine, met een voorvoegsel per team en één voor de toelatingsroute, waarin alleen het gefedereerde robotaccount van het team of de toelatingsroute schrijft en geen cluster leest; vrijgegeven, voor eigen software met hetzelfde pad als in de quarantaine, waarin alleen de overzetidentiteit schrijft; derden, waarin alleen de toelatingsroute schrijft; en spiegel, waarin alleen de spiegelidentiteit schrijft.
Toelichting
Omdat in de quarantaine wordt getekend, volstaat met parallelle voorvoegsels één RemapIdentity per ruimte bij de controle op het knooppunt. Dat Quay schrijfrecht per voorvoegsel geeft, is een voorwaarde bij de acceptatie; de terugvaloptie is een quarantaineorganisatie per team, met een RemapIdentity per team. De automatisering richt de ruimtes vanuit code in.
Ieder cluster leest met een eigen leesrobot, alleen uit de ruimtes vrijgegeven, derden en spiegel van de containerregistry van zijn cel. De leesrobot is het enige langlevende robotaccount: een beheerd geheim dat iedere 30 dagen wordt vervangen.
Toelichting
Aanvaard restrisico: een uitgelekt token geeft leestoegang tot de vrijgegeven inhoud van één cel. Dat is begrensd doordat het token alleen leest en per cluster geldt, beelden geen geheimen bevatten en het SOC de gebruikslogboeken van Quay ontvangt.
Een afgewezen beeld verdwijnt direct uit de quarantaine, een ander beeld na 7 dagen. Een vrijgegeven versie blijft zolang een cluster, een locatie of de herstelkern ernaar verwijst, en ten minste 90 dagen na haar laatste gebruik. Een toelating van derden vervalt op haar einddatum: het beeld verdwijnt uit de ruimte derden en nieuwe starts worden geweigerd.
Toelichting
De 90 dagen sluiten aan op de wekelijkse kopie die 90 dagen wordt bewaard, zodat een cluster dat daaruit wordt herbouwd zijn beelden terugvindt. Gecontroleerd met het rapport van de bewaarregel en de acceptatieproef Herbouw van een cluster.
Software van derden die niet wordt herbouwd, gaat door de toelatingsroute in de platformnaamruimte toelating op het bouwcluster: ophalen uit de toegestane bron via de proxy naar de quarantaine, controle van de controlesom tegen een publicatie buiten het downloadkanaal en van de handtekening van de leverancier (cosign verify of GPG tegen de vastgelegde sleutel), scan en onderdelenlijst met syft, Clair en roxctl, en daarna attest en handtekening met de toelatingssleutel van het platform. Pas dan komt het beeld in de ruimte derden, waaruit wordt uitgerold.
Toelichting
Het toelatingsattest koppelt bron, versie, controlesom, datum, scan en besluit aan het beeld; het is geen verklaring dat RWS de software zelf heeft gebouwd. Een kant-en-klaar product gaat niet om de inhoudelijke controles heen: een onderdelenlijst wordt gemaakt als de leverancier die niet meelevert. Pakketten en configuratiesjablonen van derden gebruikt een bouw alleen na deze route, omdat de toelatingscontrole van de clusters alleen containerbeelden ziet.
Iedere toelating heeft een eigenaar en een einddatum. Het register in de opslagplaats Catalogus heeft per beeld één bestand met eigenaar, bron, versie, controlesom, of de leverancier heeft ondertekend, het besluit en de einddatum. Een aanvraag is een wijzigingsvoorstel op het register, beoordeeld door de productverantwoordelijke en de beveiligingsadviseur; de aanvrager schrijft niet zelf in de ruimte derden. Herbeoordeling volgt ten minste jaarlijks en bij iedere nieuwe versie, naast de dagelijkse scan.
Toelichting
Een ontbrekende handtekening of herkomstverklaring van de leverancier staat in het register als aanvaard risico; de toelatingshandtekening vervangt haar niet. De eigenaar krijgt 30 dagen vóór de einddatum een melding; zonder herbeoordeling vervalt de toelating. Per beeld is er een abonnement op de kwetsbaarheidsmeldingen van Trusted Profile Analyzer. Gecontroleerd met het rapport van beelden in de ruimte derden zonder geldig attest of met verstreken einddatum, en met de acceptatieproef Softwareketen.
Voor de controle op besmetting in de herstelomgeving levert de toelatingsroute de schijfbeelden van de herstelservers en, als ondertekend artefact, de definities van de eindpuntbeveiliging met de indicatoren van het SOC; als terugvaloptie een open scanner.
Alle leverancierssoftware, dus containerbeelden, operators, besturingssysteempakketten en firmware, komt via de spiegel binnen, met de handtekeningcontrole die de leverancier per soort biedt en een spiegelverslag per versie met bron, versie, controlesom en uitkomst van de controle. Voor clusterversies en operators uit de spiegel aanvaardt de toelatingscontrole de handtekening van de leverancier, gecontroleerd bij spiegelen en bij ophalen. De clusters staan in hun beeldconfiguratie alleen de spiegel en de eigen containerregistry toe.
Toelichting
De uitzondering betreft welke ondertekening wordt vertrouwd, niet het weglaten van de controle. Platformreleases vallen onder het standaardbeleid ‘openshift’ voor de handtekening van Red Hat, operatorbeelden onder een eigen beleid met RemapIdentity naar de spiegel. Dat dit laatste werkt, is een voorwaarde bij de acceptatie; anders blijft de handtekeningcontrole bij het spiegelen de controle op die beelden. Gecontroleerd met de compliancecontrole op toegestane registries en een netwerktest.
Na de opbouw spiegelt de automatisering in de cel van het bouwcluster met oc-mirror en de spiegelset per versie uit de opslagplaats Platform, via de proxy, naar de ruimte spiegel; het spiegelverslag komt in de opslagplaats Platform. Afhankelijke operators staan expliciet in de spiegelset. Dezelfde route via de proxy haalt ook de kwetsbaarheidsgegevens op.
Toelichting
Zo is er één route via de proxy. De spiegel wordt gerepliceerd als andere vrijgegeven inhoud, en de andere cel kan met dezelfde spiegelset ook zelf spiegelen. Het spiegelen tijdens de opbouw valt hierbuiten.
Iedere cel heeft een eigen containerregistry met Quay op haar basisdienstencluster. Samen vormen de registries één gelaagde inrichting die vrijgegeven inhoud tussen de cellen repliceert, zodat een cel bij verbindingsverlies zelfstandig doorwerkt.
Toelichting
In de eerste levering is er één containerregistry, in cel 1; die van cel 2 komt met groeipadstap 2. De inrichting van Quay als basisdienst staat in het domein basisdiensten.
De automatisering van de ontvangende cel haalt vrijgegeven inhoud op uit de containerregistry van de andere cel en controleert handtekening en attesten vóór plaatsing; er is geen gedeelde database. Iedere cel heeft daarvoor een eigen replicatie-identiteit en een vastgelegde stroom over de koppeling tussen de cellen.
Toelichting
Een vervalst beeld komt zo niet verder; in groeipadstap 2 wordt dat aangetoond met een vervalst testbeeld dat de ontvangende cel weigert. Afgewezen: geo-replicatie van Quay met één gedeelde database, waarbij beide cellen aan één database hangen en een fout in de bron zich verspreidt.
In de catalogus moeten nog worden vastgelegd: de vaste inhoudskenmerken, de vingerafdrukken van de sleutels, de paden van de opslagplaatsen en de toegestane bronnen.