De standaardinrichting

De standaardinrichting van ieder applicatiecluster bestaat uit de onderdelen hieronder, elk met de voorziening die het afdwingt.

De standaardinrichting bestaat uit zeven beleidspakketten in de opslagplaats Beleid, geplaatst op clusters met de functie ‘applicatie’: aanmelding en rollen; naamruimten en werklasten; netwerk en ingang; certificaten, geheimen en identiteit; toelating, beveiligingsbewaking en uitrol; compliance en logging; opslag en back-up. Pakketten voor de database en het dienstennetwerk komen op kenmerk erbij. Ieder pakket heeft een eigen versie en doorloopt afzonderlijk ‘melden’, de proefgroep en de uitrolgolven.

Nieuw beleid in de standaardinrichting gaat van ‘melden’ via de proefgroep per uitrolgolf naar ‘afdwingen’, en alleen tijdelijk terug: voor één golf of als uitzondering met einddatum. Geeft een nieuwe versie fouten, dan gaat zij in versiebeheer terug naar de vorige versie, en het vlootbeheer rolt die terugzetting eerst bij de proefgroep uit.

Een wijziging van een beheerd object buiten versiebeheer wordt binnen 5 minuten gemeld en, waar het beleid afdwingt, teruggezet. De tijd tot dat herstel wordt gemeten.

Een afwijking van de standaardinrichting bestaat alleen als goedgekeurde uitzondering met eigenaar, compenserende maatregel en een einddatum van ten hoogste zes maanden, zichtbaar in het nalevingsoverzicht.

Teams hebben geen rechten op platformnaamruimten, clusterbrede objecten of operators en maken geen naamruimten aan. Een poging om de standaardinrichting te wijzigen, via portaal, API of een eigen controller, op netwerkbeleid, quotum, rollen of toelatingsbeleid, wordt geweigerd en gemeld.

Teamnaamruimten ontstaan alleen uit de dienstbeschrijving, zodat er geen naamruimte zonder grenzen bestaat.

Iedere teamnaamruimte heeft een ResourceQuota, een LimitRange, een NetworkPolicy die alleen ingang en DNS toelaat, een EgressFirewall ‘default’ met een afsluitende weigerregel, ACL-logging en de labels voor profiel en toelatingscontrole.

Iedere werklast heeft limieten voor processor en geheugen, en iedere naamruimte van een team een quotum. Werklasten zonder eigen limieten krijgen standaardwaarden. Het quotum begrenst de aangevraagde capaciteit bij toelating, maar reserveert niets.

Sensor, opslagkoppeling, Argo CD en andere onderdelen met meer rechten draaien in platformnaamruimten, met een eigen profiel en zonder teamrechten.

Containers draaien met het striktste profiel (restricted, met seccomp), zonder verhoogde rechten, hostnetwerk of toegang tot de werker, met SELinux in afdwingende stand op ieder knooppunt. Een team kan het profiel niet verruimen. Werklasten met verhoogde eisen in bedrijfskritische productie draaien vanaf groeipadstap 4 in een aparte sandbox. Een afwijking kan alleen met een besluit, voor platformonderdelen en voor bouwtaken op het bouwcluster.

Werklasten laden of starten tijdens gebruik geen uitvoerbare software van buiten de containerregistry. Het standaardsjabloon zet een alleen-lezen rootbestandssysteem; een beschrijfbaar rootbestandssysteem wordt in ontwikkelen en beproeven gemeld en in reguliere en bedrijfskritische productie geweigerd, en uitvoeren vanuit schrijfbare mappen wordt altijd geweigerd. De sensor meldt het downloaden en uitvoeren van code tijdens gebruik, en uitgaand verkeer is begrensd.

Het besturingssysteem van de knooppunten is onveranderbaar, op de schrijfbare configuratie- en gegevensmappen na, en alleen via de machineconfiguratie in versiebeheer te beheren. De bestandsintegriteit wordt ten minste ieder kwartier gecontroleerd en een onverwachte wijziging wordt gemeld. Buiten de noodroute is er geen rechtstreekse aanmelding op knooppunten.

Alleen ondertekende software uit de eigen containerregistry of leverancierssoftware uit de spiegel start, gecontroleerd door de toelatingscontrole en door de werker bij het ophalen. Beleid zet het label policy.rhtas.com/include op alle teamnaamruimten en zet het terug als het verdwijnt; het knooppunt controleert de handtekening in elk geval. De toelatingscontrole van de beveiligingsbewaking (SecuredCluster met admissionControl enforcement) staat in ontwikkelen en beproeven op failurePolicy Ignore en in reguliere en bedrijfskritische productie op Fail, na beproeving.

Ontwikkel-, test- en productieomgevingen zijn gescheiden: een team heeft aparte clusters voor ontwikkelen en beproeven en voor reguliere productie, en er komen geen productiegegevens in ontwikkelen en beproeven zonder besluit van de gegevenseigenaar.

Voor clusters gelden zeven beveiligingseisen. De tabel noemt ze, met de invulling die het ontwerp eraan geeft.

Ieder cluster voldoet aan het baselineprofiel. Het wordt wekelijks en na iedere wijziging van de standaardinrichting gescand, en de integriteit van de werkers wordt iedere 900 seconden gecontroleerd. Er is geen open afwijking met hoog risico zonder goedgekeurde uitzondering met einddatum; het nalevingsoverzicht toont de laatste scandatum en hoort bij iedere levering. De gehoste besturing wordt op het clusterbeheer gecontroleerd.

De audit gaat versleuteld en met bevestigde ontvangst naar de SIEM van het SOC. Het clusterbeheer stuurt de audit van de API-servers; rechtstreeks gaan de audit van de werkers, de ACL-logboeken van netwerkbeleid en EgressFirewall en de meldingen van de beveiligingsbewaking. Het auditprofiel is WriteRequestBodies, met geheimen, routes en OAuth-clients alleen op metadataniveau. Zolang de eigen bewakingsvoorziening er niet is, blijft de dienst in het profiel ontwikkelen en beproeven.

Ieder applicatiecluster bewaakt zichzelf en meldt rechtstreeks aan zijn meldingsroutes; een verzamelaar stuurt een vaste selectie metingen naar het vlootbeheer. Opslagmeetwaarden per cluster komen uit de bewakingsvoorziening, niet van de exporter van het opslagcluster. De meldingen staan in de tabel.

De inventaris van clusters, knooppunten, naamruimten, werklasten en operators komt uit de zoekfunctie van Advanced Cluster Management, die van beelden en hun gebruik uit Quay met de scanresultaten van Clair, en die van apparatuur en netwerken uit NetBox. Een geplande taak in Ansible Automation Platform schrijft dagelijks een samenvatting per dienst met eigenaar naar NetBox en meldt verschillen.

Afnemers zijn op vijf lagen gescheiden: cluster (eigen besturing en etcd-sleutel), netwerk (VLAN, routeringsdomein per profiel en beheerdersbeleid), identiteit (groepen per team, identiteiten per cluster en naamruimte), opslag (namespace, subvolumegroep en CephX-gebruikers per cluster) en quota (per naamruimte, op de werkervirtualisatie en op het opslagcluster). Wat afnemers scheidt, kan een team niet wijzigen; de koppelvlakken staan in de tabel.