De gekozen versie per product, met de ondersteuningsstatus en de technische grenzen waar het ontwerp rekening mee houdt. Versies zijn ondersteunde combinaties die de leverancier bevestigt.
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
Per product ligt de gekozen versie vast, met de ondersteuningsstatus en de technische grenzen waar het ontwerp rekening
mee houdt. Versies zijn door de leverancier ondersteunde combinaties; opensourceproducten zonder leverancierscontract
staan in eigen beheer. De versies van de opslagstapel en van OpenShift liggen vast met het ontwerp van de opslag.
Waarom zo
Een versie is alleen bruikbaar als de hele combinatie wordt ondersteund, ook tijdens een upgrade. Daarom bevestigt de
leverancier iedere combinatie vóór de ingebruikname en heeft iedere voorwaarde een terugvaloptie.
Versies en ondersteuningstermijnen veranderen snel. De versies hier zijn een voorstel met de stand bij de keuze; voor de
actuele stand gelden de feiten uit de publieke documentatie, en de levenscycluscontrole volgt de versies die hier staan.
Versies zijn door de leverancier ondersteunde productcombinaties uit deze productlijst. Een overgang naar een volgende versie start ten minste 3 maanden vóór het einde van de ondersteuning, en een versie buiten de lijst vraagt een ontwerpbesluit van de architect.
Toelichting
Gecontroleerd in het versieoverzicht van het vlootbeheer. Voor de actuele versies en ondersteuningstermijnen gelden de feiten uit de publieke documentatie van de leveranciers; de levenscycluscontrole volgt de versies die hier staan.
De leverancier bevestigt de ondersteuning van iedere combinatie, ook van de tussenliggende upgradecombinaties, vóór de acceptatie van het onderdeel waarin zij wordt ingezet; die bevestiging hoort bij de definitie van gereed. Een geslaagde proef in de leeromgeving vervangt haar niet. Zonder ondersteuning geldt de terugvaloptie van het product, of blijft de laatst bevestigde combinatie in gebruik.
Toelichting
Eigenaar: platformbeheer en leveranciersmanagement.
OpenBao, NetBox en Forgejo zijn opensourceproducten zonder leverancierscontract; hun ondersteuningsstatus is ‘eigen beheer’. Platformbeheer beheert ze zelf: alleen versies binnen het versiebeleid van het project, beveiligingsupdates binnen de termijnen van het patchbeleid en per product een onderhoudsplan met de contactroute naar het project.
Toelichting
De jaarlijkse herziening van de beveiligingsbaseline beoordeelt of een ondersteuningscontract nodig is.
Voor operators en onderdelen zonder eigen gekozen versie, zoals de Red Hat build of OpenTelemetry en de onderdelen van de eigen bewakingsvoorziening (Thanos, Grafana en Data Foundation in interne modus), geldt de versie die de leverancier bij OpenShift 4.22 ondersteunt. Zoals bij alle operators wordt die versie bij de spiegeling op inhoudskenmerk vastgelegd.
Toelichting
Bij de eigen bewakingsvoorziening is de ondersteuning een voorwaarde bij de ingebruikname, met een terugvaloptie. Thanos en Grafana voor de samengevatte metingen van de vloot zijn onderdeel van Advanced Cluster Management 2.17.
Functies die de leverancier als Technology Preview levert, worden in de eerste levering niet gebruikt. Dat geldt onder meer voor de geavanceerde velden voor directe OIDC-aanmelding en gevirtualiseerde besturingsknooppunten via KubeVirt Redfish in OpenShift 4.22, de Perses-dashboards van de observability en de integratie met de Argo CD Agent in Advanced Cluster Management 2.17, en de Forgejo-koppeling van Pipelines as Code. Een combinatie die de leverancier niet als ondersteund noemt, wordt eerst in de leeromgeving beproefd.
Toelichting
De Argo CD Agent zelf is in OpenShift GitOps sinds 1.19 algemeen beschikbaar.
Het clusterplatform is OpenShift Container Platform 4.22, op Kubernetes 1.35, voor alle platformclusters en gehoste clusters. Het is een even versie met verlengde ondersteuning.
De opslagstapel is Red Hat Enterprise Linux 10 met Red Hat Ceph Storage 9.1 voor het opslagcluster, en OpenShift Data Foundation 4.22 in externe modus voor de koppeling van de clusters, op OpenShift 4.22.
Het ontwerp van de opslag, met de bevestiging door Red Hat en de terugvaloptie, staat in het domein Opslag & foutdomeinen. Multicloud Object Gateway wordt niet ingezet.
Het exportscript van de opslagkoppeling ondersteunt per cluster een eigen RADOS-namespace, een subvolumegroep, beperkte rechten en sleutelrotatie; de parameters uit zijn uitvoer, zoals blokpool, bestandssysteem en adres van de objecttoegang, mogen na de koppeling op het opslagcluster niet meer wijzigen. De koppeling maakt alleen opslagklassen aan voor diensten die op het opslagcluster draaien: bestandsopslag vraagt een metadatadienst, objectopslag een objectgateway.
Toelichting
Multicloud Object Gateway staat in externe modus uit (reconcileStrategy ignore); dat wordt in de leeromgeving beproefd. Bij CephFS-volumes met veel bestanden vertraagt het herlabelen voor SELinux de start van een pod.
Installatie en spiegelen gebruiken de agent-based installer, de oc-mirror-plug-in versie 2 en de mirror registry for Red Hat OpenShift als tijdelijke registry tijdens de opbouw, alle onderdeel van OpenShift 4.22.
De gehoste besturing gebruikt de multicluster engine for Kubernetes 2.12 met hosted control planes, op het KubeVirt-platform met externe infrastructuur; die versie ondersteunt OpenShift 4.20 tot en met 4.22 als beheer- en gastcluster.
Enkele velden van een gehost cluster zijn na het aanmaken onveranderbaar: publicatie van diensten, opslag van etcd, gegevens voor externe infrastructuur, opslagstuurprogramma, wijze van werkervervanging en beschikbaarheidsbeleid van de besturing. Gehoste besturing ondersteunt geen IPsec tussen knooppunten. Een back-up met OADP van een gehost cluster op OpenShift Virtualization is volgens de leverancier alleen op hetzelfde beheercluster terug te zetten; de virtuele werkers worden daarbij opnieuw gemaakt en gegevens van gastvolumes op externe infrastructuur gaan niet mee. Voor herstel heeft het API-adres een vaste hostnaam nodig.
De clusters gebruiken de ingebouwde OAuth-server van OpenShift, met Red Hat build of Keycloak als OpenID-aanbieder. etcd wordt versleuteld met AES-GCM op platformclusters en met AES-CBC op gehoste clusters. Het platform zet de hybride sleuteluitwisseling X25519MLKEM768 niet uit; bij TLS 1.3 gebruiken API-server, kubelet en ingang haar automatisch, etcd niet.
Toelichting
Rechtstreekse aanmelding via een externe OIDC-aanbieder is sinds OpenShift 4.20 algemeen beschikbaar, maar ondersteunt één aanbieder en schakelt de ingebouwde OAuth-server en het installatieaccount uit. Versleuteling van etcd via een externe KMS is in 4.22 een Technology Preview die alleen HashiCorp Vault Enterprise ondersteunt. Het TLS-profiel Modern staat alleen TLS 1.3 toe.
Een user-defined network wordt vóór de start van de toepassingen aangelegd en is daarna onveranderbaar; OpenShift Virtualization ondersteunt alleen de topologieën Layer2 en Localnet, en clusterbrede definities blijven bij platformbeheer. Route-aankondiging via BGP en de EVPN-koppeling van een ClusterUserDefinedNetwork, met een VTEP per knooppunt en een VNI per netwerk, zijn in OpenShift 4.22 algemeen beschikbaar op clusters met fysieke werkers, maar niet samen met IPsec of EgressIP en niet bij gehoste besturing; de modus zonder overlay is nog Technology Preview.
Toelichting
Red Hat beschrijft de EVPN-koppeling en de schaaltest met 3.500 localnet-netwerken met een tweede netwerkkaart per knooppunt, en een localnet-netwerk op de standaardbrug br-ex zonder uitspraak over de doorvoer. Omdat iedere server één bundel heeft, wordt in de leeromgeving de werking aangetoond van een VLAN-interface op die bundel als VTEP en van localnet-netwerken op br-ex. De doorvoer wordt gemeten met de doorvoertest van het datacenternetwerk: voor localnet-netwerken bij de acceptatie van de werkervirtualisatie, voor de VTEP bij de invoering van de EVPN-koppeling; lukt dat niet, dan krijgen de betrokken servers een tweede kaart in het vrije uitbreidingsslot. Bij virtuele werkers verzorgt het datacenternetwerk de aansluiting. AdminNetworkPolicy en BaselineAdminNetworkPolicy hebben in 4.22 nog API-versie v1alpha1; de overstap naar de opvolger ClusterNetworkPolicy volgt pas als OpenShift die als ondersteunde functie levert. Een EgressFirewall telt ten hoogste 8.000 regels.
Het datacenternetwerk gebruikt Cisco Nexus 9000 in NX-OS-modus met NX-OS 10.6(4)M (augustus 2026), en Cisco Nexus Dashboard als fabriccontroller: 4.2.1 zolang de automatiseringscollectie 4.3 niet ondersteunt, daarna 4.3.1.
Per switchmodel is een NX-OS-release met de gebruikte functies, zoals het opsplitsen van poorten, EVPN-multihoming, MACsec en Multi-Site, een voorwaarde bij de fase van de netwerklevering die ze inzet; anders blijft de laatst bevestigde versie in gebruik.
Het vlootbeheer gebruikt Red Hat Advanced Cluster Management 2.17 (juli 2026), dat bij multicluster engine 2.12 hoort, op OpenShift 4.22. Versiecontroles gebruiken het nummer uit de release notes van Advanced Cluster Management, omdat de nummers van beide producten niet gelijk lopen.
Voorwaarde bij de ingebruikname: Red Hat ondersteunt de hub met deze versies op OpenShift 4.22, de import van multicluster engine 2.12 op het clusterbeheer en het automatisch importeren van gehoste clusters, ook in de tussenliggende upgradecombinaties; anders blijft de laatst ondersteunde combinatie in gebruik. Thanos en Grafana voor de samengevatte metingen zijn onderdeel van deze versie.
Back-up van de clusters, ook van het vlootbeheer, gebruikt OpenShift API for Data Protection (OADP) 1.6 op Velero 1.18; de onveranderbare kopie staat op Cohesity, met DataLock en FortKnox, ook voor virtuele servers. De ondersteuningsopgave van OADP 1.5 noemt OpenShift 4.22 niet.
Velero herschrijft de metagegevens van een back-up bij het afronden en kan daardoor niet rechtstreeks naar een vergrendelde bestemming schrijven. De back-upvoorziening haalt de back-ups daarom op uit de objectopslag van de cel; dat is een voorwaarde bij de ingebruikname van het herstel, en lukt het met de versie van RWS niet, dan zet een afzonderlijke kopieertaak ze op een vergrendeld S3-doel van Cohesity. De koppeling en een onafhankelijke herstelproef horen bij die ingebruikname.
Logging gebruikt Red Hat OpenShift Logging 6.6 (juli 2026; 6.6.1 actueel) met de Loki Operator, voor OpenShift 4.20 tot en met 4.22; daarmee gaat onder meer de audit van het vlootcluster naar de SIEM. Versie 6.5 heeft sinds 14 augustus 2026 alleen onderhoudsondersteuning.
De bewaking van apparatuur in de eigen bewakingsvoorziening, vanaf groeipadstap 2, gebruikt exporters, met snmp_exporter 0.30.1. Zabbix blijft in gebruik tot de eigen bewakingsvoorziening alle apparatuur aantoonbaar bewaakt; daarna is er geen afzonderlijk bewakingsproduct.
Tekton Chains ondersteunt ondertekenen zonder sleutel via Fulcio, met een identiteit van SPIFFE of van een OIDC-aanbieder. Red Hat heeft de combinatie met de Fulcio-dienst van Trusted Artifact Signer en de applicatie-identiteit van de pijplijn op het bouwcluster niet als geheel gedocumenteerd; zij wordt eerst in de leeromgeving gekwalificeerd. Tot ondertekenen zonder sleutel in groeipadstap 2 wordt ingevoerd, tekent Chains met een sleutel waartoe alleen de Chains-besturing toegang heeft.
Ondertekening en toelating gebruiken Red Hat Trusted Artifact Signer 1.4.2 met de Policy Controller en Cosign 3.0.4, naast de ClusterImagePolicy van OpenShift, die sinds 4.20 algemeen beschikbaar is.
De Policy Controller van Trusted Artifact Signer 1.4 herkent geen handtekeningen die via de OCI-referrers-API zijn opgeslagen, het standaardformaat van Cosign 3; ondertekenen gebeurt daarom in het oude bundelformaat. Hij controleert alleen naamruimten met het label policy.rhtas.com/include op true. Een eigen ClusterImagePolicy van OpenShift mag niet ‘openshift’ heten: die naam is gereserveerd en een conflict blokkeert updates. De werking van de ClusterImagePolicy in gehoste clusters is een voorwaarde bij de ingebruikname van de softwarelevering en van het applicatiecluster als dienst; zonder die werking weigert alleen de toelatingscontrole, onder een uitzondering met compenserende maatregel en einddatum.
De syslog-koppeling in CEF-formaat is niet declaratief in te richten; de automatisering richt haar in via de API. Het Compliance Dashboard is in 4.11 verwijderd; de resultaten van de Compliance Operator staan in de complianceweergave en de rapportage.
Nalevingscontrole en integriteitsbewaking gebruiken de Compliance Operator 1.10, met CIS-profielen volgens benchmark v2.0.0, en de File Integrity Operator 1.4.0. Versie 1.10 is volledig ondersteund tot 15 december 2026 en 1.4.0 tot 6 oktober 2026; die laatste wordt bij de inrichting van de beveiligingsbaseline vervangen door de dan geldende opvolger.
Red Hat test cert-manager en de External Secrets Operator met HashiCorp Vault, niet met OpenBao; de vault-koppeling wordt voor OpenBao gebruikt en vooraf in de leeromgeving beproefd.
Geheimen in clusters gebruiken de External Secrets Operator for Red Hat OpenShift 1.2.1, gebaseerd op upstream 2.5.0, met de vault-koppeling naar OpenBao.
Voor tijdelijke inloggegevens in werklasten biedt External Secrets geen bevestigde ondersteuning. De eerste levering gebruikt daarom de agent-injector van OpenBao; de Helm-chart gebruikt daarvoor nog het injectorbeeld van het Vault-project (1.7.2), omdat OpenBao nog geen eigen beeld heeft.
Toelichting
Voorwaarde bij de ingebruikname van het applicatiecluster als dienst: de agent-injector verlengt leases automatisch en vervangt inloggegevens zonder onderbreking, aangetoond in de leeromgeving en bij de acceptatie. Lukt dat niet, dan levert de CSI-provider van OpenBao (2.0.3) de inloggegevens. Hoe een toepassing haar geheimen krijgt, is een open beslispunt.
De applicatie-identiteit gebruikt Red Hat Zero Trust Workload Identity Manager 1.1.1 (SPIFFE en SPIRE), algemeen beschikbaar sinds december 2025; versie 1.1 is volledig ondersteund tot 16 november 2026. Een ondersteunde opvolger is een voorwaarde bij de ingebruikname van het applicatiecluster als dienst.
Het identiteitsbeheer gebruikt midPoint 4.10 van Evolveum, ondersteund tot 26 november 2027, met PostgreSQL 17. De tussenversie 4.11 (oktober 2026, kortere ondersteuning) en 4.8 LTS (tot 17 oktober 2028) worden niet gebruikt; de overstap naar een volgende versie, zoals LTS 5.0, gaat via een ontwerpbesluit vóór het einde van de ondersteuning van 4.10.
midPoint is geen Red Hat-product; ondersteuning loopt via een abonnement bij Evolveum of een partner. Sinds 4.10 ondersteunt midPoint alleen PostgreSQL 14 tot en met 17, met 17 als aanbeveling. De koppeling met Red Hat build of Keycloak loopt via een connector voor de beheer-API, in een vastgezette versie en onder het abonnement van midPoint; dat is een voorwaarde bij de ingebruikname van de basisdiensten. Terugvaloptie is een draaiboek van de automatisering tegen de beheer-API, ieder uur gestart door midPoint. De connector wordt in de leeromgeving beproefd, ook bij iedere upgrade van Keycloak.
Het geheimenbeheer gebruikt OpenBao 2.6.3 (23 september 2026) met Helm-chart 0.29.6; die versie herstelt onder meer een beveiligingsfout in de Kubernetes-authenticatie. Het gaat naar 2.7 zodra de Helm-chart die levert en de ontgrendeling met de plug-in is beproefd.
OpenBao 2.6 ontgrendelt automatisch via KMS-plug-ins, die alleen in het configuratiebestand te registreren zijn. OpenBao 2.7.0, van dezelfde datum, verwijdert de ingebouwde leveranciersspecifieke seals, zodat pkcs11 alleen nog via de plug-in openbao-plugin-kms-pkcs11 werkt terwijl transit ingebouwd blijft, en verwijdert de ingebouwde aanmeldmethoden LDAP, Kerberos en RADIUS; nieuw zijn sleutels in een HSM of KMS voor PKI en transit, en ML-DSA. Auditapparaten worden in het configuratiebestand vastgelegd, omdat aanmaken via de API een onveilige instelling vraagt.
De datacenterregistratie gebruikt NetBox 4.7.1 (september 2026), minimaal 4.7.1, omdat 4.7.0 bij het terugzetten van een databasedump triggers verliest.
De community-Helm-chart 8.3.85 installeert 4.7.1; chart- en beeldversie worden beide vastgezet. De Ansible-collectie netbox.netbox documenteert ondersteuning tot NetBox 4.5; de automatisering wordt tegen 4.7 beproefd.
Het firmwarebeheer gebruikt HPE OneView 11.4, de door HPE aanbevolen versie, met de collectie hpe.oneview 11.4.0, als virtuele machine op OpenShift Virtualization.
OneView wordt geleverd als virtueel apparaat voor VMware ESXi, Microsoft Hyper-V of KVM; de ondersteuning op OpenShift Virtualization en de benodigde capaciteit zijn een voorwaarde bij de ingebruikname van de basisdiensten. Bevestigt HPE deze opstelling niet, dan loopt het firmwarebeheer via de Redfish-API van iLO met draaiboeken in Ansible Automation Platform, met dezelfde basislijn en hetzelfde nalevingsoverzicht.
De externe verkeersverdeling gebruikt NetScaler BLX 14.1, minimaal build 73.32 vanwege kritieke kwetsbaarheden in eerdere builds (actueel 73.33, augustus 2026), op virtuele machines met Red Hat Enterprise Linux 9, met de collectie netscaler.adc 2.17.0.
BLX draait als pakket op Linux in plaats van als virtuele appliance VPX. Zo is het ontwerp niet gebonden aan de beperkte ondersteuningsmatrix en de netwerkgrenzen van de VPX-appliance op OpenShift Virtualization, en kan iedere afnemer een eigen HA-paar krijgen op het basisdienstencluster. BLX werkt hier alleen op laag 4, als TCP-doorgifte zonder TLS-afsluiting; het ondersteunt onder meer RHEL 9 en Ubuntu 22.04, vraagt ten minste 2 GB geheugen en werkt met of zonder DPDK op een virtuele machine met virtio. De ondersteuning in deze opstelling en de licentie per exemplaar zijn een voorwaarde bij de ingebruikname van de basisdiensten; de doorvoer zonder DPDK wordt alleen gemeten. Bevestigt NetScaler de opstelling niet vóór de inrichting van de ingang, dan gebruikt het platform NetScaler VPX op OpenShift Virtualization, met dezelfde inrichting en paren.
Het versiebeheer van het platform gebruikt Forgejo 15.0 LTS met Forgejo Actions, ondersteund tot 15 juli 2027; 16.0 is actueel tot 15 oktober 2026. De overstap naar de volgende LTS-versie, 19.0, gepland op 15 april 2027 en ondersteund tot 13 juli 2028, valt vóór het einde van de ondersteuning van 15.0.
Volgens de documentatie van de Helm-chart is Forgejo nog niet geschikt voor meerdere actieve exemplaren: wachtrijen, geplande taken en cache kennen geen leider. Het versiebeheer draait daarom als één exemplaar dat na uitval op een ander knooppunt herstart; sinds versie 14 levert de Helm-chart geen PostgreSQL en Valkey meer mee en komt de database van CloudNativePG. Forgejo 15.0 heeft geen afzonderlijk auditlogboek voor beveiligingsgebeurtenissen; de logbron voor het SOC bestaat daarom structureel uit het toegangslogboek, de aanmeldgebeurtenissen van Keycloak en een dagelijkse vergelijking van rechten en beschermingsregels met de vastgelegde waarden, waarbuiten een wijziging valt die binnen een dag is teruggedraaid. De runner van Forgejo Actions draait in een eigen virtuele machine, in de kortlevende modus en zonder geprivilegieerde containers.
De beheerwerkplek gebruikt een toegangsgateway met sessievastlegging, Apache Guacamole 1.6.0 of gelijkwaardig, en geharde beheerservers als virtuele machines op het basisdienstencluster. Zij vervangt de voorlopige beheerwerkplek van de opbouw en handhaaft met het identiteitsbeheer de bevoorrechte sessies.
De beheerde database gebruikt CloudNativePG 1.30.1 met de Barman Cloud-plug-in 0.15.0, met ondersteuning via EDB Postgres for Kubernetes. Versie 1.30 is ondersteund tot circa december 2026; de overstap naar 1.31 start uiterlijk 3 maanden eerder, tijdens de bouw van de beheerde database.
CloudNativePG verwijdert in 1.31 de ingebouwde back-upmethode naar objectopslag; de eerste levering gebruikt direct de Barman Cloud-plug-in. Bevestigt de leverancier de stapel van de beheerde database niet, dan wordt EDB Postgres for Kubernetes gebruikt, in de versie die de leverancier bij OpenShift 4.22 ondersteunt en met dezelfde instellingen; tot die overgang blijft de beheerde database in het profiel ontwikkelen en beproeven.
De digitale assistent is in 1.10 een algemeen beschikbare plug-in, maar werkt alleen met een gekoppeld taalmodel en wordt pas na beoordeling voor afnemers ingezet. Publiceren vanuit softwaresjablonen is algemeen beschikbaar naar GitHub en een Technology Preview naar GitLab. Developer Hub kent geen ondersteunde Forgejo-koppeling: de upstreammodule voor Gitea maakt alleen opslagplaatsen aan, geen wijzigingsvoorstellen; het portaal gebruikt daarom de API van Forgejo.
Het dienstennetwerk gebruikt Red Hat OpenShift Service Mesh 3.4.2 (Istio 1.30, Kiali 2.27, juli 2026), volledig ondersteund tot 11 januari 2027 en zonder verlengde ondersteuning. In de doelsituatie is het onderdeel van de standaardinrichting; de eerste levering bevat nog geen dienstennetwerk.
De lichte vorm (ambient) is algemeen beschikbaar, met een ztunnel per knooppunt voor laag 4 en een waypoint per naamruimte voor laag 7; nieuw in 3.4 zijn nftables, beide vormen naast elkaar in één dienstennetwerk, controle op ingetrokken certificaten in ztunnel en optionele netwerkregels voor de eigen onderdelen. Certificaten komen via cert-manager (istio-csr) uit de eigen PKI, en platformbeheer schakelt bij de ingebruikname de hybride quantumveilige sleuteluitwisseling X25519MLKEM768 in. De lichte vorm vraagt OVN-Kubernetes met routering via het knooppunt en is alleen ter plekke bij te werken; virtuele machines kunnen er niet aan deelnemen en per cluster is één dienstennetwerk in de lichte vorm mogelijk. Gehoste besturing staat niet bij de ondersteunde opstellingen en wordt vóór inschakeling in de leeromgeving beproefd. De koppeling met de SPIRE-identiteit is een Technology Preview en werkt alleen met de vorm met extra container; het dienstennetwerk gebruikt daarom eigen certificaten, met per cel dezelfde naam voor het vertrouwensdomein als SPIRE. Multicluster en dual-stack in de lichte vorm en de Gateway API Inference Extension zijn Technology Preview. De beoogde opstelling met een externe besturing is in 3.4 alleen algemeen beschikbaar in de vorm met extra container, en in de lichte vorm is alleen multi-primary beschikbaar, als Technology Preview; daarom bevat de eerste levering geen dienstennetwerk.
De diensten voor wisselende belasting gebruiken Red Hat OpenShift Serverless 1.37 (1.37.1), met Serverless Logic 1.38 als werkstroommotor voor werkstromen als dienst en PostgreSQL als toestandsopslag, vanaf groeipadstap 4.