Het clusterbeheer

Naast de applicatieclusters van teams draagt het clusterbeheer de gehoste clusters met een platformfunctie: het bouwcluster, het portaalcluster en, zodra het dienstennetwerk in gebruik is, het besturingscluster daarvan. Zij volgen hetzelfde ontwerp als een applicatiecluster, maar staan in de zone en het routeringsdomein platform (vrf-platform) in plaats van in een afnemerszone.

De zeven servers van het clusterbeheer volgen de rekindeling van de cel: in drie rekken staan ieder één besturings- en één werkerknooppunt, in het vierde rek alleen de koude reserveserver. Het rek staat als zonekenmerk (topology.kubernetes.io/zone) op de knooppunten, en nieuwe werkerknooppunten komen in de drie rekken van het clusterbeheer.

Iedere besturing heeft drie actieve etcd-exemplaren met gereserveerde middelen, elk op een volume van 8 GiB op de lokale opslag van een ander werkerknooppunt. De etcd-exemplaren en de overige exemplaren van de besturing staan op verschillende werkerknooppunten in verschillende rekken, zodat iedere configuratiedatabase na verlies van één werkerknooppunt met twee van de drie exemplaren haar quorum houdt.

Het clusterbeheer gebruikt geen Data Foundation en heeft geen aansluiting op het opslagclientnetwerk. LVM Storage op de vier NVMe-schijven van ieder werkerknooppunt (opslagklasse lvms-<deviceClass>) draagt de etcd-volumes en de blijvende volumes van de eigen onderdelen, zoals de clusterbewaking. Het opslagcluster dient het clusterbeheer alleen voor back-ups: een eigen RGW-gebruiker met bucket en quotum in de realm platform, die opslagbeheer via het geheimenbeheer levert.

Het clusterbeheer wordt geïnstalleerd met de agent-based installer (platform baremetal met apiVIPs en ingressVIPs), vanaf de eigen containerregistry met imageDigestSources uit de spiegel; agentconfiguratie en NMState staan in versiebeheer onder clusters/c1-cb-01/. Beelden voor het clusterbeheer en de besturingen komen alleen uit de eigen containerregistry, releasebeelden op inhoudskenmerk, en het clusterbeheer heeft geen internettoegang.

Het clusterbeheer draait alleen de multicluster engine, geen tweede hub. Het vlootbeheer importeert het clusterbeheer (configureMceImport) en neemt de gehoste clusters daarna automatisch op, zodat er één vlootbeheer blijft.

Het clusterbeheer draait OpenShift 4.22 met de multicluster engine 2.12 en gehoste besturing op het KubeVirt-platform met externe infrastructuur. In de eerste levering is alleen OpenShift 4.22 vrijgegeven.

Vijf productfuncties waarvan de ondersteuning door de leverancier niet vastligt, zijn acceptatiecriteria van het clusterbeheer, elk met een terugvaloptie. Wordt een criterium niet gehaald, dan geldt de terugvaloptie, zodat geen open einde blijft.

Aanmelding op het clusterbeheer gaat via Keycloak met meerfactoraanmelding; het gewone werk loopt via versiebeheer. Clusterbeheerrechten bestaan alleen als platformbrede verhoging van ten hoogste 4 uur, vanaf de beheerwerkplek en opgenomen, voor ten hoogste 4 personen per cel. Applicatieteams hebben geen toegang tot het clusterbeheer.

Noodtoegang tot het clusterbeheer gebruikt een certificaat uit de kluis. Ieder gebruik wordt binnen 5 minuten gemeld, en daarna wordt het certificaat ongeldig gemaakt.

Het beheerkubeconfig dat de besturing per gehost cluster in haar naamruimte op het clusterbeheer zet, verlaat het clusterbeheer niet. Alleen de multicluster engine en de import van het vlootbeheer lezen het; personen alleen via de noodroute.

Netwerkbeleid in iedere besturingsnaamruimte weigert verkeer uit andere besturingsnaamruimten. Van buiten zijn alleen API-server en routes bereikbaar, de etcd alleen vanuit de eigen besturing, en gereserveerde middelen voorkomen dat een drukke besturing een andere verdringt. Negatieve proeven tonen aan dat de identiteit op de werkervirtualisatie alleen haar eigen naamruimte bereikt, een besturing alleen haar eigen etcd en een werker alleen zijn eigen cluster.

De clusterbewaking van het clusterbeheer meet het clusterbeheer en de besturingsnaamruimten en meldt per e-mail aan platformbeheer. Het vlootbeheer ziet van buitenaf of een gehost cluster bereikbaar is en vat metingen samen met de observability-addon. Iedere meetwaarde van het clusterbeheer heeft een drempel en een melding, en capaciteit heeft een actiedrempel vóór de grens.

Voor het clusterbeheer en de gehoste besturingen gelden de meetwaarden en normen hieronder. De beschikbaarheid per profiel wordt pas bij de vrijgave voor reguliere productie aangetoond; tot dan meet het platform iedere maand de beschikbaarheid van iedere besturing als referentie.

Het clusterbeheer stuurt zijn eigen audit (auditd, kubeAPI, openshiftAPI en ovn) via syslog over TLS met een clientcertificaat naar de SIEM van het SOC. De audit van de gehoste API-servers ontstaat ook op het clusterbeheer, als containerlogboek in de besturingsnaamruimte; een eigen invoer van de logdoorsturing (ClusterLogForwarder) stuurt haar door met de clusternaam als kenmerk. De audit bevat de inhoud van schrijfacties, behalve van geheimen, en het SOC bevestigt de ontvangst per cluster.

Het clusterbeheer voldoet aan het baselineprofiel: een wekelijkse scan toetst het, en de integriteitscontrole toetst de knooppunten iedere 900 seconden. Omdat het profiel voor gastclusters de besturingsregels uitschakelt, toetst een beleid van het vlootbeheer op het clusterbeheer iedere clusterdefinitie aan de vaste waarden van het sjabloon. Een afwijking komt in het nalevingsoverzicht en wordt teruggezet.

De servers van het clusterbeheer volgen de firmwarebasislijn met beveiligde opstart en TPM, nemen de tijd van twee interne bronnen en hebben een onveranderbaar besturingssysteem met SSH alleen via de noodroute. De beveiligingssensor draait ook op het clusterbeheer, het installatieaccount is verwijderd en een schijf verlaat het datacenter niet leesbaar.

Iedere besturing versleutelt haar gevoelige objecten in etcd met aescbc en een eigen sleutel, die jaarlijks en na een incident wordt vervangen. Het clusterbeheer versleutelt zijn eigen etcd met aesgcm, met een sleutel die iedere 7 dagen wisselt. Systeemschijven en de lokale schijven onder LVM Storage zijn versleuteld met TPM2-binding.

Alle verbindingen van en naar het clusterbeheer lopen over TLS, nooit met insecureSkipTLSVerify, en de onderdelen van een besturing verbinden onderling met TLS. Het clusterbeheer krijgt geen IPsec tussen de knooppunten, net als de andere platformclusters.

Het clusterbeheer heeft een dreigingsmodel, dat de CISO-functie vóór de vrijgave voor productie goedkeurt en dat jaarlijks en bij een grote wijziging wordt herzien.

Platformbeheer is eindverantwoordelijk voor het clusterbeheer en de besturingen; tot de overdracht voert het ontwikkelteam zijn taken uit. Identiteitsbeheer levert groepen en tijdgebonden toekenningen, en het SOC bevestigt de ontvangst van de audit. Rekposities, hostnamen en adressen van het clusterbeheer worden per cel vastgelegd in het detailontwerp van de cel en in de inventaris.

Voor het clusterbeheer bestaan de draaiboeken hieronder, in de opslagplaats Draaiboeken en met de geautomatiseerde delen als taak in Ansible Automation Platform. Ieder draaiboek is vóór de overdracht door de eigen beheerders uitgevoerd en wordt daarna volgens het beproevingsschema herhaald.