1 open besluit1414 voorstellen

Onderwerp

De basisdiensten en hun plaatsing

Welke tien basisdiensten op het basisdienstencluster draaien, met welk product, hoe ze zijn ingericht en welke cel per dienst schrijft. Iedere cel heeft eigen exemplaren; alleen het versiebeheer is één voorziening voor de vloot.

Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas

Domein
Volgt uit
Functies
Producten
Verwant

Wat het is

Op het basisdienstencluster draaien tien basisdiensten, elk met een eigen product. Dit onderwerp legt vast welke dat zijn, hoe ze zijn ingericht, hoeveel exemplaren ze per cel hebben, waar hun gegevens staan, welke cel per dienst schrijft, welke interfaces afnemers zien en hoe beheerders en technische identiteiten erbij kunnen.

Het ontwerp van identiteit en beheertoegang staat in Identiteit & beheertoegang, dat van geheimen, sleutels en certificaten in Geheimen, sleutels & certificaten. Hier gaat het om het draaien van die diensten op het cluster.

Waarom zo

Iedere cel heeft eigen exemplaren uit dezelfde code, zodat een storing of aanval in de ene cel de andere niet raakt en een cel zonder de andere herstelt. Alleen het versiebeheer is één voorziening voor de vloot, omdat twee actieve exemplaren niet worden ondersteund; valt het uit, dan draaien de clusters door op hun laatste inrichting.

Afnemers krijgen alleen interfaces en nooit rechten op het cluster zelf, en iedere technische identiteit heeft één taak. Zo blijft de basis van de cel klein en controleerbaar.

Uitspraken

4 vastgesteld14 voorstellen

Alle 14 voorstellen vaststellen

De tien basisdiensten

VastgesteldUitgangspunt#

Op het basisdienstencluster draaien tien basisdiensten, elk ingevuld met één product volgens de koppeling van functies en producten.

BasisdienstProductDraait als
ContainerregistryQuay, met ClairContainers
GeheimenbeheerOpenBaoContainers
ToegangsvoorzieningRed Hat build of KeycloakContainers
IdentiteitsbeheermidPointContainers
Versiebeheer van het platformForgejoContainers
AutomatiseringAnsible Automation PlatformContainers
DatacenterregistratieNetBoxContainers
FirmwarebeheerHPE OneViewVirtuele machine
Externe verkeersverdelingNetScaler BLXVirtuele machines, als paar
BeheerwerkplekApache Guacamole als toegangsgateway, met beheerserversContainers voor de gateway, virtuele machines voor de beheerservers
Toelichting

Naam- en adresvoorziening en tijdvoorziening zijn bestaande RWS-diensten buiten het cluster; zie Startketen, opslag en herstel.

VoorstelEis#

Voor de externe verkeersverdeling en het firmwarebeheer als virtuele machine gelden voorwaarden bij de acceptatie: de leverancier ondersteunt NetScaler BLX op virtuele machines op OpenShift Virtualization, met een licentie per exemplaar, en HPE OneView op OpenShift Virtualization. Voor de verkeersverdeling moet die bevestiging er zijn voordat de inrichting van netwerk, ingang en koppelingen begint.

Toelichting

Zonder bevestiging geldt de terugvaloptie: NetScaler VPX met dezelfde inrichting en paren, en firmwarebeheer via de Redfish-API van iLO met draaiboeken van de automatisering, met dezelfde basislijn en hetzelfde nalevingsoverzicht. BLX is gekozen boven VPX; beide zijn per cel herstelbaar en uit code op te bouwen.

VoorstelOntwerpbesluit#

De externe verkeersverdeling draait steeds als hoog beschikbaar paar, met de leden op verschillende knooppunten. Eén gemeenschappelijk paar dient het platform en de afnemers zonder eigen paar; op aanvraag via de dienstbeschrijving krijgt een afnemer een eigen paar met eigen virtuele adressen en eigen beheer, binnen de capaciteit van het cluster. De inrichting loopt via de automatisering. Een paar geeft alleen TCP door; TLS eindigt bij de dienst erachter.

Toelichting

De inrichting van de verkeersverdeling zelf hoort bij Netwerk, ingang & zones.

VoorstelWaarde#

Iedere basisdienst heeft een vast aantal exemplaren per cel en een vaste plek voor haar gegevens.

BasisdienstExemplaren per celOpslag
ContainerregistryQuay en Clair elk ten minste tweeEigen databases; objecten in de realm platform van het opslagcluster
GeheimenbeheerDrie Raft-leden, één per knooppuntLokaal
ToegangsvoorzieningDrie, één per knooppuntDatabase lokaal
IdentiteitsbeheerTweeDatabase lokaal; keystore als clustergeheim
Versiebeheer van het platformEén voor de vloot, met strategie Recreate en herstart na uitsluiting; de runner als virtuele machineOpslagplaatsen op een blokvolume van het opslagcluster; bijlagen en pakketten als objecten; database lokaal
AutomatiseringIeder onderdeel twee; twee uitvoeringsknooppunten in VLAN 600Databases lokaal; opslag van de hub op CephFS
DatacenterregistratieWebtoepassing en takenverwerker elk tweeDatabase lokaal; bijlagen op CephFS
FirmwarebeheerEén virtuele machine in VLAN 600, herstart na uitsluitingOp het opslagcluster
Externe verkeersverdelingParen, met de leden op verschillende knooppunten20 GB lokaal per lid
BeheerwerkplekBeheeringang en teamingang, elk met twee exemplaren van webtoepassing en guacd; platformpool en teampool van elk twee beheerserversDatabase lokaal; opnamen in een bucket met Object Lock
Toelichting

De databases van de basisdiensten draaien op CloudNativePG, met drie exemplaren per database. Waarom welke gegevens lokaal staan, staat bij Startketen, opslag en herstel.

VoorstelWaarde#

De installatie en de opslag per basisdienst.

BasisdienstInstallatie en opslag
ContainerregistryQuay via de Quay Operator, één Quay-omgeving per cel, met quay en clair elk in ten minste twee exemplaren; de onderdelen quay, clair, redis, route en horizontalpodautoscaler door de operator beheerd; objectopslag onbeheerd met RadosGWStorage op de objectgateway van de cel; database onbeheerd op CloudNativePG; vrijgegeven inhoud gerepliceerd tussen de cellen
GeheimenbeheerOpenBao via de Helm-chart met global.openshift; hoog beschikbaar met Raft en drie exemplaren op lokale volumes (lvms-<deviceClass>), elk op een eigen knooppunt; TLS-luisteraar met een certificaat van buiten OpenBao
ToegangsvoorzieningRed Hat build of Keycloak via de operator (Keycloak-CR v2beta1), drie exemplaren; database op CloudNativePG
IdentiteitsbeheermidPoint als container met twee exemplaren; PostgreSQL op CloudNativePG; keystore als geheim
Versiebeheer van het platformForgejo via de Helm-chart, met het rootless beeld uit de containerregistry en de OpenShift-compatibiliteit van de chart; één exemplaar met strategie Recreate; opslagplaatsen op een blokvolume, bijlagen, LFS en pakketten in de objectgateway van de cel, PostgreSQL op CloudNativePG; web via een route, SSH via een adres van MetalLB; de runner voor Forgejo Actions als virtuele machine met rootless Podman
AutomatiseringAnsible Automation Platform via de operator (AnsibleAutomationPlatform-CR); databases op CloudNativePG, de hub met hstore; opslag van de hub op CephFS
DatacenterregistratieNetBox via de community-Helm-chart met vastgezette beeldversie; PostgreSQL met ltree op CloudNativePG; Valkey of Redis
FirmwarebeheerHPE OneView als virtuele machine op OpenShift Virtualization
Externe verkeersverdelingNetScaler BLX als pakket op virtuele machines met RHEL 9 op OpenShift Virtualization, als hoog beschikbaar paar, per virtuele machine ten minste 2 vCPU, 4 GB geheugen en 20 GB schijf; het gemeenschappelijke paar bij de opbouw, een eigen paar op aanvraag via de dienstbeschrijving, met een sjabloon in de opslagplaats Catalogus
BeheerwerkplekApache Guacamole met een beheeringang en een teamingang, elk met twee exemplaren van webtoepassing en guacd, database op CloudNativePG, versleuteld verkeer tussen webtoepassing en guacd; beheerservers als virtuele machines met RHEL 10, de platformpool in VLAN 600 en de teampool op het podnetwerk, met de vaste beheerhulpmiddelen; sessieopnames direct naar een bucket met Object Lock
Databases van de basisdienstenCloudNativePG met drie exemplaren per database op lokale volumes
Toelichting

De versies staan bij de softwarestapel.

VoorstelWaarde#

De aanmelding, de geheimen en de back-up per basisdienst.

BasisdienstAanmelding en geheimenBack-up
ContainerregistryOIDC-aanmelding via Keycloak; robotaccount per cluster met alleen leesrecht; onveranderbare labels en onveranderbaarheidsbeleid per organisatieDagelijks configuratie, database en bucket als één herstelpunt
GeheimenbeheerBeheerders via OIDC met Keycloak, met een toegangsbewijs van ten hoogste 1 uur; clusters via Kubernetes-authenticatie per cluster; de engines KV versie 2, database, PKI, transit en SSH; auditapparaat in het configuratiebestandRaft-momentopname ieder uur via de snapshotagent
ToegangsvoorzieningRealm platform; meerfactoraanmelding verplicht; WebAuthn en passkeys voor platformrollen; gebeurtenissen en beheergebeurtenissen naar het SOCDagelijkse back-up van de database
IdentiteitsbeheerAanmelding via Keycloak; bronnen RWS-HR en de directory; doel Keycloak; herbeoordelingscampagnesDatabase en keystore
Versiebeheer van het platformOIDC naar Keycloak met groepsclaim, groepen gekoppeld aan teams; lokale aanmelding uit; SSH-sleutels per persoon, ook voor ondertekening; repositorygebonden tokens uit OpenBao voor Argo CD, de automatisering en het portaalDagelijkse forgejo dump en doorlopende back-up van de database
AutomatiseringAanmelding via Keycloak; projecten uit de opslagplaats Draaiboeken in Forgejo met een leestoken; inloggegevens uit OpenBao via de credential-plug-in, beproefd in de leeromgeving; een goedkeuringsstap in de werkstromen voor productie—
DatacenterregistratieOIDC-aanmelding via Keycloak; API-token per automatiseringsidentiteitDagelijks
FirmwarebeheerAanmelding via de directory; lokale beheerder in de kluisEigen back-upfunctie van het apparaat
Externe verkeersverdelingBeheer via de NITRO-API met de collectie netscaler.adc; beheeraccount per paar in het geheimenbeheer, noodaccount in de kluis; RHEL 9 gehard volgens de basislijn van de beheerservers voor zover die van toepassing is; alleen TCP-doorgifte, zonder certificaten of TLS-profiel op het paarConfiguratieback-up na iedere wijziging
BeheerwerkplekOIDC via Keycloak met meerfactoraanmelding; verbindingen alleen naar de beheerservers en de toegestane beheerinterfaces; beheeringang alleen vanuit het apparatuurbeheernetwerk, teamingang via de externe verkeersverdeling; noodwerkplek in de kluis, met rechtstreekse toegang tot iLO en de beheerserver van het opslagclusterOpnames 1 jaar bewaard
Databases van de basisdienstenTLS 1.3Barman Cloud-plug-in naar de objectgateway van de cel, voor herstel binnen de cel; de productiebescherming is de onveranderbare kopie
VoorstelEis#

Iedere basisdienst voldoet aantoonbaar aan een eigen eis voordat zij als werkend geldt.

BasisdienstWerkt als
ContainerregistryClusters worden zonder rechtstreekse internettoegang geïnstalleerd en bijgewerkt
GeheimenbeheerEen geheim wordt zonder onderbreking vervangen voor koppelingen die twee geldige waarden tegelijk of herladen zonder herstart ondersteunen, en een herstel met de herstelsleutels is uitgevoerd
ToegangsvoorzieningPlatformonderdelen worden via deze aanmelding beheerd; onderdelen die alleen een directory- of API-identiteit ondersteunen, staan met eigenaar als uitzondering geregistreerd
IdentiteitsbeheerInstroom, wijziging en vertrek werken automatisch door: een ingetrokken toegang werkt binnen één uur nergens meer, ook niet in lopende sessies en toegangsbewijzen; de eerste herbeoordeling is uitgevoerd
Versiebeheer van het platformHet vlootbeheer en de automatisering halen de inrichting alleen hieruit
AutomatiseringUitvoering in productie alleen na goedkeuring; iedere uitvoering is vastgelegd
DatacenterregistratieDe automatisering haalt de adressen uit de registratie
FirmwarebeheerAfwijkingen van de basislijn zijn zichtbaar en herstelbaar
Externe verkeersverdelingHet inrichten van een eigen paar stoort het verkeer van andere afnemers niet
BeheerwerkplekBeheer loopt alleen via de gateway; de voorlopige beheerwerkplek is uitgeschakeld nadat de noodwerkplek is beproefd

Over de cellen

VastgesteldRegel#

Iedere basisdienst heeft in iedere cel een eigen exemplaar uit dezelfde code, met eigen gegevens, behalve het versiebeheer. Een cel werkt en herstelt zonder de andere; over de cellen heen gaan alleen het versiebeheer, de vlootbrede rollen en de vlootbrede voorzieningen.

Toelichting

Toegangsvoorziening en identiteitsbeheer zijn per cel en delen alleen hun bronnen bij RWS; zie De identiteitsketen. Aangetoond in groeipadstap 2 met de toets Herstel na een aanval.

VastgesteldOntwerpbesluit#

Het versiebeheer van het platform is één voorziening voor de hele vloot en draait in de eerste levering in beheercel 1. Valt het uit, dan draaien alle clusters door op hun laatst ontvangen inrichting; wijzigingen, nieuwe uitrol en het terugzetten van afgedwaalde inrichting wachten, behalve handmatig via de noodroute. Bij verlies van beheercel 1 wordt het uit de onveranderbare kopie opnieuw opgebouwd in beheercel 2; tot die cel er is, begint dat herstel bij de herstelkern.

VoorstelWaarde#

Per basisdienst ligt vast of cel 2 een tweede exemplaar krijgt en welke cel schrijft.

BasisdienstTweede exemplaar in cel 2Schrijvende cel
ContainerregistryJa, gevuld door replicatieCel 1 voor vrijgaven; cel 2 haalt op en controleert
GeheimenbeheerJa, met eigen geheimen en een eigen tussen-CA, zonder replicatieIedere cel; de ondertekeningssleutel en de tussen-CA ‘ondertekening’ alleen in cel 1
ToegangsvoorzieningJaIedere cel; vlootdiensten melden zich aan bij cel 1
IdentiteitsbeheerJa, met dezelfde bronnen en code, zonder replicatieIedere cel; de vlootbrede rollen kent cel 1 toe, na uitsluiting van cel 1 cel 2
Versiebeheer van het platformNee; code en capaciteit staan in cel 2 klaar voor herbouw uit de onveranderbare kopieCel 1
AutomatiseringJa; de draaiboeken komen vlootbreed uit het versiebeheerIedere cel; een overname draait op de automatisering van de ontvangende cel
DatacenterregistratieJa, met de gegevens van de celIedere cel
FirmwarebeheerJaIedere cel
Externe verkeersverdelingJaIedere cel
BeheerwerkplekJaIedere cel
Toelichting

RWS-breed, met een vlootbrede rol, zijn de containerregistry, het versiebeheer, de automatisering en de ondertekeningssleutel. Van het versiebeheer staan in cel 2 alleen code en capaciteit klaar.

VoorstelRegel#

Per basisdienst schrijft de cel die daarvoor is aangewezen. Een overname door de andere cel loopt via een draaiboek, pas na uitsluiting van de oude kant, en draait op de automatisering van de ontvangende cel; de terugkeer is een aparte stap.

Toelichting

Beproefd met een overnameproef in groeipadstap 2.

Afnemers en interfaces

VoorstelRegel#

Afnemers zien alleen de interfaces van de basisdiensten, zonder rechten op het cluster of op zijn virtuele machines. Paden, rollen en koppelingen voor een toepassing maakt het platform bij de levering aan. Het firmwarebeheer en de datacenterregistratie hebben alleen platformbeheer, netwerkbeheer en de automatisering als gebruiker, de datacenterregistratie ook de runner; de beheerwerkplek daarnaast teams met een verhoging.

Toelichting

Zie de dienst Applicatie-identiteit en geheimenbeheer.

VoorstelWaarde#

De interfaces van de basisdiensten, met hun afnemers, isolatie en grenzen.

InterfaceAfnemerIsolatieGrens of quotumBijzonderheden
Containerregistry: ophalenClusters van de celLeesrobot per cluster, alleen op vrijgegeven software, software van derden en de spiegelCapaciteit van de realm platform—
Containerregistry: plaatsenPijplijnen van teams; de toelatingsrouteGefedereerd robotaccount op de eigen quarantaineruimte; toegangsbewijs ten hoogste 15 minutenOnveranderbare versielabelsVrijgave door het platform
Geheimenbeheer: geheimen en tijdelijke inloggegevensWerklasten via de geheimenkoppeling; platformdienstenEigen mount per cluster; beleid per pad, onder apps/<team>/<toepassing> en platform/<cluster>/Aanvraaggrens per mountVaste patronen voor geheimen en tijdelijke inloggegevens; database-engine voor de beheerde databases
Geheimenbeheer: certificatencert-manager op ieder cluster van de celRol per domein, voor de dienstnamen van bedrijfskritische diensten een rol per dienst uit de tussen-CA ‘vloot’; naambeperkingTen hoogste 2160 uurPublieke certificaten komen uit de externe PKI, als geheim bij de route
Geheimenbeheer: transit en SSHOndertekenfunctie en pijplijnen; verhoging en noodrouteEigen sleutel en beleid per gebruik; de sleutel verlaat het geheimenbeheer nietTen hoogste 1 uur voor knooppunten en personen, 15 minuten voor pijplijnenOndertekening alleen in cel 1
ToegangsvoorzieningClusters, platformdiensten, beheerders en toepassingenRealm en clients volgens Aanmelding en sessies—Het vlootcluster gebruikt die van cel 1
IdentiteitsbeheerToegangsvoorziening; bronnen RWS-HR en AD DSEigen exemplaar per cel—Rollenmodel volgens Rollen, groepen en rechten
VersiebeheerVlootbeheer, automatisering, portaal, bouwcluster en beheerdersRepositorygebonden leestokens, voor het bouwcluster alleen de sjabloonresolver in Catalogus; pijplijnen van platformsoftware met een SSH-certificaat van 15 minuten; teams alleen via de opslagplaats Afnemers—De broncode van toepassingen staat in GitLab
AutomatiseringPlatformbeheer, het leverpad en een overnameEigen exemplaar per cel; inloggegevens per taak uit het geheimenbeheerGoedkeuring vóór uitvoering in productieProjecten uit de opslagplaats Draaiboeken
Externe verkeersverdelingHet platform en de afnemers zonder eigen paar; afnemers met een eigen paarEigen virtuele machines, virtuele adressen en beheeraccount per paarBudget van het basisdienstenclusterTCP-doorgifte; TLS eindigt bij de dienst

Toegang tot de basisdiensten

VoorstelRegel#

Personen melden zich bij iedere basisdienst aan via de toegangsvoorziening van de cel met meerfactoraanmelding, of via de directory waar het product geen OIDC kent, zoals het firmwarebeheer. Toegang via API en automatisering gebruikt eigen, vastgelegde identiteiten. Lokale beheerdersaccounts zijn uitgeschakeld of liggen als noodaccount in de kluis. Een ingetrokken toegang werkt binnen 1 uur in geen enkele basisdienst meer.

Toelichting

Aangetoond met een proef per dienst en de toets Beheertoegang en noodtoegang. De regels voor aanmelding en intrekking staan in Aanmelding en sessies en bij de norm voor intrekking.

VoorstelRegel#

Beheer van de basisdiensten loopt alleen via de beheerwerkplek, met persoonlijk account, meerfactoraanmelding, tijdelijke verhoging en opname van iedere bevoorrechte sessie. Voor het geheimenbeheer is dat een platformbrede verhoging binnen één cel; de vlootbrede rollen vragen daarnaast een hardwaresleutel.

Toelichting

Zie De beheerwerkplek.

VoorstelRegel#

Lokale accounts bestaan alleen als noodtoegang in de kluis, onafhankelijk van de toegangsvoorziening: twee noodaccounts per cel in Keycloak, het certificaat-kubeconfig van het basisdienstencluster en de lokale beheerder van Forgejo, midPoint, OneView, ieder lid van de externe verkeersverdeling en iLO. Ieder gebruik is binnen 5 minuten bij het SOC gemeld, en daarna wordt de noodtoegang vervangen.

Toelichting

Halfjaarlijks getest. De noodroute zelf staat in Noodtoegang, uitval en herstel.

VoorstelRegel#

Rechten en technische identiteiten gelden per cel, behalve de vlootbrede rollen, en iedere technische identiteit heeft één taak, een eigenaar en minimale rechten. Bij de basisdiensten zijn dat een leesrobot per cluster in Quay, als enig langlevend robotaccount; schrijvende robotaccounts, gefedereerd met de OIDC-uitgevers van pijplijnen en automatisering; repositorygebonden tokens in Forgejo; een API-token per automatiseringsidentiteit en voor de runner in NetBox; en een beheeraccount per paar van de externe verkeersverdeling. Hun geheimen staan in het geheimenbeheer.

Toelichting

Gecontroleerd met een rechtenrapport. De algemene regels staan bij Rollen, groepen en rechten.

Verwijzen hiernaar

Onderwerpen 6