Onderwerp
Bevestigd door vdo89 op 28 september 2026. Eigenaar: vdo89. Bron in de atlas
Alle clusters van een cel gebruiken hetzelfde opslagcluster. Iedere afnemer krijgt daarin een afgeschermde ruimte: een eigen namespace voor blokopslag, een eigen subvolumegroep voor bestandsopslag, en in de objectopslag een eigen tenant binnen de realm van zijn vertrouwensdomein. De sleutels daarvoor zijn per cluster, met alleen de rechten op die eigen ruimte, en komen uit het geheimenbeheer.
Een gedeeld opslagcluster is alleen veilig als het ene cluster niet bij de gegevens van het andere kan, ook niet bij een fout in de rechten. Eigen sleutels per cluster zijn apart in te trekken; realms per vertrouwensdomein houden platformdiensten en afnemers gescheiden, ook als een bucketbeleid fout staat. Versleuteling van alle schijven en van al het opslagverkeer beschermt ook de gegevens van toepassingen en databases die zelf niet versleutelen.
Ieder cluster dat koppelt, krijgt een eigen ruimte met quotum en toegangssleutels voor alleen die ruimte. Een cluster kan de ruimte van een ander niet lezen, beschrijven of verwijderen, en er geen momentopnamen of klonen van maken; negatieve proeven tonen dat aan.
Eén pool en één sleutel voor alle clusters geeft geen afscherming; een pool per cluster geeft honderden pools met eigen placement groups, een onnodige belasting van het opslagcluster.
Blokopslag is een gedeelde pool met een RADOS-namespace per cluster, met eigen CephX-gebruikers die alleen rechten hebben op die namespace. Een quotum per namespace is niet mogelijk: aan de platformkant begrenst de ResourceQuota per naamruimte en opslagklasse de aangevraagde capaciteit, met het poolquotum als achtervang, en het feitelijke verbruik per namespace wordt gemeten.
Bestandsopslag is een gedeeld bestandssysteem met per cluster een subvolumegroep met naamruimte-isolatie en het quotum uit de dienstbeschrijving. De CephX-gebruikers zijn beperkt tot de eigen groep.
Een gedeeld bestandsvolume is begrensd tot één miljoen bestanden; grotere verzamelingen gaan naar objectopslag. Pods die één volume delen, draaien met dezelfde SELinux-categorieën, zodat maar één keer wordt herlabeld.
Zodra OpenShift de mount-optie voor een vaste SELinux-context standaard levert en die onder representatieve belasting is beproefd, vervallen deze twee beperkingen.
Objectopslag heeft per vertrouwensdomein een eigen realm met eigen gebruikers, sleutels en objectgateways: platform, afnemers-ontwikkelen en afnemers-regulier, en afnemers-bedrijfskritisch bij de vrijgave van het profiel bedrijfskritische productie. Nooit de realmnaam default. Een fout in de rechten van een gebruiker of bucket werkt niet over de grens van een realm heen; tegen fouten in het beheer van het opslagcluster zelf beschermt de realm niet.
Een realm komt er alleen bij voor een nieuw vertrouwensdomein, met eigen pools en objectgateways. Een realm per cluster vraagt bij 200 clusters te veel pools en placement groups.
Objectopslag als dienst voor afnemers heeft per afnemer een RGW-tenant en per toepassing een gebruiker met quotum. De back-up van een applicatiecluster krijgt in de realm platform een eigen RGW-gebruiker en bucket, door de automatisering aangemaakt en via het geheimenbeheer geleverd.
Iedere realm heeft eigen objectgateways achter een eigen virtueel adres en een eigen naam onder s3.<cel>.dc3.internal, alleen binnen het datacenter bereikbaar. Het certificaat komt uit de PKI van het geheimenbeheer onder de interne PKI, geldt 90 dagen en wordt 30 en 7 dagen vóór verloop gemeld.
Alleen platformclusters krijgen een beheersleutel voor de objectopslag. Applicatieclusters krijgen geen beheergebruiker en dus geen objectopslagklasse via Data Foundation, alleen een eigen back-upgebruiker: een beheergebruiker zou hun rechten geven op alle gebruikers en buckets van de realm.
Ieder OpenShift-cluster krijgt eigen CephX-gebruikers met minimale rechten. Opslagbeheer maakt ze aan, begrenst hun rechten en trekt ze in, via het exportscript; OpenShift krijgt nooit een beheergebruiker van het opslagcluster zelf.
De uitvoer van het exportscript gaat versleuteld naar het geheimenbeheer van de cel, in het pad platform/<cluster>/opslag; External Secrets zet haar als geheim in de naamruimte openshift-storage, waar Data Foundation haar nodig heeft. Geheimen gaan nooit via tickets, chat of e-mail.
CephX-sleutels worden alleen vervangen bij een incident of een vermoeden van compromittering, met de sleutelrotatie van het exportscript en een nieuwe uitvoer; periodieke vervanging voegt complexiteit toe zonder aantoonbaar voordeel. Bij beëindiging van een cluster worden ze ingetrokken. De werking, ook het weigeren van de oude sleutel, wordt in de leeromgeving beproefd.
Dit is een bewuste uitzondering op de vervangtermijn die voor andere langlevende geheimen wordt voorgesteld; die termijn geldt niet voor de koppelsleutels van het opslagcluster.
Alle OSD-schijven zijn versleuteld in rust met LUKS2 (dmcrypt). De schijfsleutels staan in de configuratiedatabase van de monitors en vallen onder hun back-up, met een herstelkopie buiten de cel, gescheiden van de gegevens. Een afgevoerde schijf is zonder die sleutels onleesbaar.
Al het Ceph-protocolverkeer van en binnen het opslagcluster is versleuteld met messenger v2 in de beveiligde modus, zonder IPsec tussen de knooppunten. Objectgateway, dashboard en bewaking gebruiken TLS 1.2 of hoger; de certificaatcontrole wordt per eindpunt vastgelegd en beproefd.
Versleuteling per volume via de KMS-koppeling van Data Foundation met het geheimenbeheer valt buiten de eerste levering. Na beproeving in de leeromgeving wordt zij aangeboden als optie voor bedrijfskritische productie of voor een classificatie die dat vereist.
Een herstel met de herstelkopie van de schijfsleutels is uitgevoerd en aangetoond, en hangt niet af van de getroffen cel: de herstelsleutels liggen buiten de cel.