Opbouw en beheer van de werkervirtualisatie

De werkervirtualisatie draait OpenShift 4.22 met OpenShift Virtualization 4.22, dat met de versie van OpenShift meegaat. Data Foundation volgt de combinatie die opslagbeheer voor het opslagcluster bevestigt, en de cryptografie volgt per pad de cryptografietabel van RWS. De stapel staat in de tabel.

De werkervirtualisatie heeft zes acceptatiecriteria, elk met een terugvaloptie; vier daarvan betreffen productfuncties waarvan de ondersteuning door de leverancier niet vastligt.

De basislijn van de werkervirtualisatie en de instellingen van de virtualisatie staan in de tabel.

De inrichting van de werkervirtualisatie staat volledig in de opslagplaats Platform; een handmatige wijziging wordt binnen 5 minuten gemeld en teruggezet.

Een wijziging aan de werkervirtualisatie gaat met twee beoordelaars naast de auteur eerst naar de leeromgeving en dan cel na cel, vóór de gehoste clusters. Nieuw beleid gaat na een geslaagde proef van ‘melden’ naar ‘afdwingen’, en alleen tijdelijk terug: als terugvaloptie tijdens een uitrol of als uitzondering met einddatum.

Machines en netwerken staan als Kubernetes-objecten in versiebeheer; de objectsoorten van de virtualisatie zijn vastgelegd als leverancierspecifieke uitbreiding.

Op de werkervirtualisatie draait alleen software uit de spiegel en de containerregistry van de cel, en een machine start alleen uit een vrijgegeven beeld.

Aanmelding op de werkervirtualisatie gaat via de ingebouwde OAuth-server met Red Hat build of Keycloak en meerfactoraanmelding, alleen vanaf de beheerwerkplek. Platformbeheerders lezen blijvend en wijzigen via versiebeheer; clusterbeheerrechten en foutopsporing op een knooppunt zijn een platformbrede verhoging. Iedere bevoorrechte handeling loopt via de toegangsvoorziening en de beheerwerkplek, met tijdelijke verhoging, en wordt opgenomen.

Iedere technische identiteit op de werkervirtualisatie heeft een eigenaar en alleen rechten voor haar taak in haar eigen cel. Per applicatiecluster is er één identiteit met rechten alleen in clusters-<naam>; daarnaast zijn er die van OADP en van de logverzamelaar.

Geheimen van de werkervirtualisatie komen alleen uit het geheimenbeheer: de CephX-sleutels via External Secrets uit het pad platform/c1-vw-01/opslag, de infra-kubeconfig per applicatiecluster als beheerd langlevend geheim in het register. Een infra-kubeconfig wordt iedere 30 dagen vervangen, uiterlijk na 90 dagen, en die vervanging wordt zonder onderbreking beproefd. De lokale beheerder van iLO en het certificaat-kubeconfig voor noodtoegang liggen in de fysieke kluis.

Machines bereiken de API van de werkervirtualisatie niet; SELinux in afdwingende stand scheidt hun processen, en toegangslijsten op de leaf scheiden de werkers op VLAN 620. Afnemers starten op de werkervirtualisatie nooit containers.

Een team heeft geen rechten op de werkervirtualisatie en wijzigt capaciteit via de dienstbeschrijving. Een afnemer van virtuele servers beheert alleen de machines in zijn eigen naamruimte; consoletoegang loopt via de beheerwerkplek, in productie met een verhoging binnen de eigen dienst, en wordt opgenomen.

De werkervirtualisatie voldoet aan het baselineprofiel, met SELinux in afdwingende stand. De knooppunten worden wekelijks gescand en hun integriteit wordt ieder kwartier gecontroleerd.

Iedere server start alleen met ondertekende firmware, Secure Boot en TPM, staat binnen 30 dagen weer op de firmwarebasislijn van zijn type en neemt de tijd van twee interne bronnen. iLO is alleen bereikbaar in VLAN 600, zonder standaardaccounts; systeemschijven zijn versleuteld en een afgevoerde schijf is onleesbaar.

De logdoorsturing (ClusterLogForwarder) stuurt de systeemaudit van de knooppunten, de integriteitsmeldingen en de audit van de clusterbesturing versleuteld naar de SIEM van het SOC. Die audit bevat de verzoekinhoud van schrijfacties behalve geheimen, ook voor machines: starten, verhuizen, verwijderen en console. iLO en OneView sturen syslog. Het SOC bevestigt de ontvangst en bewaart een kopie buiten het bereik van platformbeheer.

De ingebouwde bewaking van de werkervirtualisatie meldt rechtstreeks via de meldingsroutes van het platform; het vlootbeheer haalt de samengevatte metingen op en controleert van buitenaf of de werkervirtualisatie bereikbaar is. Iedere meetwaarde in de tabel heeft een drempel, een actie en een ontvanger.

Knooppunten, machines, segmenten en adressen staan met eigenaar in de inventaris; een verschil is binnen 1 dag zichtbaar.

Iedere belofte van de werkervirtualisatie heeft een proef met slaagcriterium, en ieder draaiboek is vóór productie beproefd. Vóór de ingebruikname toont cel 1 de bewijzen in de tabel.

Platformbeheer is eindverantwoordelijk voor de werkervirtualisatie; tot de overdracht voert het ontwikkelteam de levenscyclustaken uit. Per locatie werkt platformbeheer het ontwerp uit in een detailontwerp met hostnamen, rekposities, adressen en VLAN-nummers. De taken zijn verdeeld zoals in de tabel.

Voor de werkervirtualisatie bestaan de draaiboeken in de tabel, in de opslagplaats Draaiboeken; primaire en plaatsvervangende beheerders voeren ze vóór de overdracht zelf uit.