Bare-Metal Kubernetes DevSecOps Plattform (KRITIS)

💡 Begründung: Die Plattform erfüllt alle Kriterien der Stufe 5: offene, vollständig dokumentierte Kubernetes/OpenShift REST-APIs, fertige Operatoren und Konnektoren für Middleware-Integration (3scale API Management, Camel-K als EAI/ESB-Lösung, Service Mesh), sowie vollständige API-Abdeckung aller UI-Funktionen.

💡 Begründung: Mit dem integrierten Prometheus/Thanos-Stack, Loki für Log-Aggregation, Tempo für Distributed Tracing, Alertmanager für Alarmierung und ACS für Netzwerk-Policy-Monitoring bietet die Plattform starkes Built-in Interface Monitoring und klare operative Diagnostik – entspricht Stufe 5 der Bewertungsskala.

💡 Begründung: Die Kombination aus Kubernetes RBAC mit pfadgenauer Namespace-Isolation, OpenShift-eigenen SCC (Security Context Constraints), ACM Policy-Enforcement und ABAC-Elementen erfüllt die höchste Stufe: granulares RBAC plus Policy Control. Vordefinierte Templates und vollständige Anpassbarkeit sind gegeben.

💡 Begründung: SCIM wird von OpenShift nicht nativ als vollständiger User-Lifecycle-Standard unterstützt, daher kein Score 5. OIDC mit modernem Auth und grundlegendem Group-Provisioning ist vorhanden, was Score 4 rechtfertigt. Für vollständiges SCIM wären externe IDM-Lösungen (z.B. Keycloak) notwendig.

💡 Begründung: Beide Protokolle (OIDC und SAML) sind self-service konfigurierbar, Dokumentation ist umfangreich vorhanden, Zertifikatsrotation und vollständiger SSO-Lifecycle können kundenautark gemanagt werden – dies entspricht der Höchstwertung (Score 5).

💡 Begründung: OpenShift-Projekte entsprechen den 'top-level isolated units' der Skala mit dedizierten Repos (Registries via Quay), Usern, Gruppen und Berechtigungen. Netzwerkisolation, Ressourcenquotas und ACM-Policies vervollständigen die Trennung – Score 5 ist gerechtfertigt.

💡 Begründung: Quay benötigt mandatorisch eine externe PostgreSQL-Datenbank (Score 4-Kriterium: specific external DB mandatory), jedoch ist die DB-Wahl auf PostgreSQL limitiert und etcd ist intern. Da nicht alle Komponenten flexible externe DB-Unterstützung bieten und Oracle/MSSQL nicht unterstützt werden, ist Score 3 konservativ aber angemessen.

💡 Begründung: Die native Unterstützung von S3, Azure Blob und GCS in Quay entspricht der höchsten Stufe 'Full Native Cloud Storage'. Zusätzlich bietet ODF ein internes S3-kompatibles Backend, was die Flexibilität weiter erhöht – Score 5 ist klar gerechtfertigt.

💡 Begründung: Die vorhandenen Cleanup-Funktionen (Tag-Expiry, scheduled Garbage Collection) entsprechen 'Basic Scheduled Cleanup' (Score 3). Eine reichhaltige Policy-Engine mit multiplen Kriterien oder echtes Archiv-Tiering (S3 Glacier) ist in Quay nicht nativ implementiert, daher kein Score 4 oder 5.

💡 Begründung: ROSA (Red Hat OpenShift Service on AWS) und ARO (Azure Red Hat OpenShift) sind managed Services, aber kein klassisches multi-tenant SaaS. On-Premise und PaaS-Deployments sind exzellent unterstützt. Da kein primäres Vendor-SaaS im klassischen Sinne vorhanden ist, Score 4 statt 5.

💡 Begründung: Die Gesamtanforderungen der Platform Plus (Control Plane + ACM + ACS + Quay + ODF) sind erheblich und liegen deutlich über 'moderatem Footprint'. Für Bare-Metal-Deployments mit allen Komponenten sind hohe Hardware-Investitionen notwendig, was Score 2 ('Hoher Hardware-Bedarf') rechtfertigt. Containerisierung ist zwar vollständig gegeben, aber der Gesamtfootprint ist groß.

💡 Begründung: Der IPI- und Assisted Installer automatisieren den Großteil der Installation, und offizielle Ansible Playbooks/Skripte sind vorhanden. Da jedoch manuelle Vorbereitungsschritte (Netzwerkkonfiguration, DNS, Infrastruktur-Prereqs) erforderlich sind, ist Score 4 ('Scripted Installation') angemessen statt Score 5.

💡 Begründung: ACM als zentrale Schaltstelle (Hub-and-Spoke), Quay Geo-Replication und ODF Stretch Cluster erfüllen gemeinsam alle Kriterien der höchsten Stufe: aktiv-aktiv/aktiv-passiv Federation, zentrale Metadaten-Synchronisierung und lokale Caching-Möglichkeiten. Score 5 ist eindeutig gerechtfertigt.

💡 Begründung: Die Architektur ist für Enterprise-Scale ausgelegt und liefert gute Performance. Für sehr große Deployments (viele Cluster, hohe Image-Pull-Rates) ist Tuning notwendig (etcd-Optimierung, Netzwerk-MTU, ODF-Performance-Tuning), was Score 4 statt 5 rechtfertigt. Die Grundarchitektur ist jedoch solide für Standard-Enterprise-Workloads.

💡 Begründung: Das Produkt bietet ein bewährtes, robustes Skalierungsmodell mit Auto-Scaling auf Pod- und Node-Ebene, Multi-Cluster-Management via ACM und verteiltem Storage via ODF. Dies entspricht 'Proven strong concurrency model with robust scaling' = Score 5.

💡 Begründung: Starke Mechanismen für verteilte Szenarien (Geo-Replikation, Mirror, SNO/Edge), aber kein dediziertes CDN oder umfassendes WAN-Optimierungsfeature on-premise. Entspricht 'Good mitigation mechanisms for most distributed usage scenarios' = Score 4.

💡 Begründung: Standardkonfigurationen und Berechtigungen sind ohne Code möglich, aber viele administrative Aufgaben erfordern YAML-Kenntnisse oder CLI-Nutzung. Kein Low-Code/No-Code-UI im klassischen Sinne für alle Szenarien. Entspricht 'Basic no-code customization for standard settings; advanced needs require coding' = Score 3.

💡 Begründung: Vollständiges Entwicklermodell mit dokumentierten APIs, offiziellem Operator SDK, CRDs, Webhooks und klarer Deployment-/Support-Guidance. Entspricht 'Full customer development model with documented APIs plus official extension/plugin mechanisms' = Score 5.

💡 Begründung: Starke RBAC- und Identity-Integration ermöglichen Offshore-Kollaboration gut; explizite 'Guest/External User'-Konzepte wie bei spezialisierten DevSecOps-Plattformen fehlen etwas, aber operativ gut unterstützt. Entspricht Score 4.

💡 Begründung: Natives, reiches Extension-Modell mit Operators/CRDs/Webhooks/Events/Plugins entspricht 'Rich native extension model (plugins/scripts/extensions) plus API/event hooks for deep side-by-side customization' = Score 5.

💡 Begründung: Starke zentralisierte Kontrollen mit guter Automatisierbarkeit (GitOps, ACM Policies), leichte Komplexität bei der operativen Pflege über viele Teams. Entspricht 'Strong centralized controls with good maintainability' = Score 4.

💡 Begründung: Der überwiegende Teil des Stacks ist Open Source (upstream-Projekte), RH-spezifische Teile sind source-available. Vollständige Fork-/Modifikationsfähigkeit des gesamten kommerziellen Produkts ist eingeschränkt. Entspricht 'Source largely available (open-core/source-available) with substantial review capability' = Score 4.

💡 Begründung: Klare Cadence, OTA-Upgrades mit Rollback, EUS-Channels für Stabilität und schnelle Security-Errata entsprechen 'Clear frequent release cadence, fast security handling, and well-structured upgrade guidance minimizing regression risk' = Score 5.

💡 Begründung: Umfassendes HA- und Recovery-Modell mit Stretch Cluster, Multi-Cluster-Failover, etcd-HA und dokumentiertem Backup/Restore (Velero/OADP). Entspricht 'Comprehensive HA and recovery model with strong documented mechanisms' = Score 5.

💡 Begründung: Rolling Upgrades mit MachineConfigOperator, PDB-Support und vollständig orchestrierter Node-Drain-Prozess entsprechen 'No or near-zero downtime upgrades are standard in supported production patterns' = Score 5.

💡 Begründung: Bei On-Premise-Deployment gibt es keine Provider-seitige Uptime-SLA für die Plattformverfügbarkeit; nur Support-SLAs existieren. Entspricht 'Limited formal SLA relevance for typical deployment model' = Score 2.

💡 Begründung: Die Plattform richtet sich klar an erfahrene Platform-Engineers und Kubernetes-Spezialisten. Die Vielzahl an Komponenten (ACM, ACS, Quay, ODF etc.) und deren Konfigurationstiefe macht schnelles Onboarding ohne umfangreiche Schulung praktisch unmöglich. Laut Skala: 'steeper learning curve; frequent guidance required' trifft zu – Score 2.

💡 Begründung: PatternFly sorgt für eine erkennbare Konsistenz innerhalb der OpenShift-Konsole, jedoch weisen eingebettete Komponenten wie ACS (StackRox), Quay oder ACM teilweise eigenständige UIs mit unterschiedlichen Interaktionsmustern auf. Theming-Optionen sind moderat. Score 3 ('Generally consistent but with limited adaptation options') passt.

💡 Begründung: Es gibt grundlegende Wizards und Guided-Flows für häufige Aufgaben, aber für fortgeschrittene operative Aufgaben fehlt interaktive In-Product-Unterstützung weitgehend. Die umfangreiche Red-Hat-Dokumentation kompensiert dies extern, nicht aber in der UI selbst. Score 3 ('Basic documentation-driven guidance, limited in-product assistance').

💡 Begründung: Die Trennung in Developer/Admin-Perspektive ist ein positives Zeichen für Use-Case-orientiertes Design. Dennoch entstehen bei komplexen Aufgaben (z. B. Bare-Metal-Provisionierung, ODF-Konfiguration, ACS-Policy-Management) spürbare Brüche zwischen Konsolen-Komponenten. Score 3 ('Adequate fit with some friction in common tasks').

💡 Begründung: Die CLI (oc, kubectl) bietet erfahrenen Nutzern hohe Produktivität, die Web-UI hingegen verfügt über begrenzte Keyboard-Navigation und Power-User-Features. Filterung und Suche funktionieren für gängige Aufgaben, skalieren aber bei sehr großen Umgebungen eingeschränkt. Score 3 ('Basic productivity functions available').

💡 Begründung: OpenShift erlaubt Cluster-Admin-seitiges Branding (Custom Logo, Login-Seite), aber persönliche Nutzer-Präferenzen wie Theme-Wahl, Dashboard-Layouts oder Verhaltenseinstellungen sind kaum vorhanden. Laut Skala: 'Limited personalization options' entspricht Score 2.

💡 Begründung: Red Hat OpenShift richtet sich als globales Enterprise-Produkt primär an englischsprachige Nutzung. Vollständige UI-Lokalisierung für mehrere Sprachen ist nicht offiziell als Feature vermarktet oder umfassend umgesetzt. Score 2 ('Limited language/localization support') ist konservativ und angemessen.

💡 Begründung: PatternFly als Basis-Framework bringt dokumentiertes Accessibility-Commitment mit, was über minimale Unterstützung hinausgeht. Jedoch sind nicht alle Konsolen-Bereiche (insb. ACS-Dashboard, Quay-UI) vollständig barrierefrei. Score 3 ('Moderate support with some gaps') ist angemessen.

💡 Begründung: OpenShift bietet technische Grundlagen (deklarative APIs, GitOps, Operator Framework), aber kein natives Master Data Management oder eine direkte Integration zu REF-MDS-Systemen. Die Plattform ist ein Enabler, nicht ein vollständiger Löser dieser Anforderung – daher Teilerfüllung, Skala 3.

💡 Begründung: Da es sich um eine Bare-Metal/On-Premise-Lösung handelt, liegt die Serverstandortwahl vollständig beim Kunden (EU, DE). Bevorzugte Hyperscaler (Azure, AWS) werden als Deployment-Option unterstützt. Minimale Einschränkung: Red Hat/IBM-Supportprozesse und Telemetrie könnten US-Bezüge haben, was kleine Abzüge rechtfertigt – Score 4.

💡 Begründung: Starke Verschlüsselungsgrundlage ist vorhanden (etcd, TLS, ODF-Encryption, FIPS-Unterstützung), jedoch sind nicht alle Verschlüsselungsoptionen per Default aktiviert – z.B. muss etcd-Verschlüsselung manuell konfiguriert werden. FIPS-Modus und SC-Klassifizierungen (0-3) werden durch DISA STIG-Mappings adressiert. Score 4 entspricht guter Abdeckung mit deployment-abhängigen Aspekten.

💡 Begründung: Als On-Premise-Produkt ist die DSGVO-Kontrolle primär beim Kunden. Red Hat bietet Standard-Vertragsklauseln und GDPR-Dokumentation, jedoch ist die Evidenz für vollständige BDSG-Konformität, transparente Subprozessor-Ketten und automatisierte Löschunterstützung begrenzt bzw. erfordert eigene Governance-Maßnahmen. Score 3 für grundlegende Compliance mit begrenzten Nachweisen.

💡 Begründung: ISO 27001 ist für Red Hat/IBM als Unternehmensstandard verfügbar, ergänzt durch FedRAMP, SOC 2, DISA STIG und Common Criteria – das entspricht starker Zertifizierungsbreite. Für die Bare-Metal-Plattform selbst sind produktspezifische Zertifizierungen (nicht nur Unternehmensebene) teilweise indirekt, daher Score 4 statt 5.

💡 Begründung: Starke API-basierte Export/Import-Unterstützung über Standard-Kubernetes-APIs, Velero, oc CLI und Quay-Registry. GitOps ermöglicht vollständigen Konfigurations-Export. Leichte Einschränkung: keine nativen GUI-basierten Massen-Upload-Funktionen (Excel o.ä.) – das ist bei einer Container-Plattform architekturbedingt, entspricht aber nicht dem vollen Score 5. Score 4 ist angemessen.

💡 Begründung: Obwohl Kubernetes als Basis portabel ist, schafft der OpenShift-spezifische Stack (CoreOS, Operator-Lifecycle-Manager, proprietäre APIs, Red Hat spezifische Security-Konzepte via ACS, Quay, ODF) erhebliche Vendor-Abhängigkeiten. Upstream-Kubernetes-Workloads sind teilweise portabel, aber die Plattform selbst ist schwer durch einen anderen Anbieter zu ersetzen. Score 2 gemäß Skala 'Strong platform or vendor dependency'.

💡 Begründung: Red Hat hat eine jahrelange stabile Entwicklungshistorie, ein großes Open-Source-Community-Ökosystem und wird durch IBM gestützt. Fluktuation ist im Vergleich zu kleineren Anbietern gering. Score 4 gemäß Skala 'Strong team continuity and proven delivery'.

💡 Begründung: Die Plattform ist umfangreich und komplex; Bare-Metal-Provisionierung, Air-Gap-Konfiguration und vollständige Integration aller Komponenten erfordern erhebliche Vorbereitung. Selbst mit erfahrenen Teams ist ein produktiver Betrieb realistisch erst nach 3-6+ Monaten möglich. Score 3 gemäß Skala 'Moderate lead time'.

💡 Begründung: Red Hat (IBM) ist einer der führenden Enterprise-Linux- und Kubernetes-Anbieter mit dediziertem KRITIS- und Public-Sector-Expertise, BSI-Grundschutz-Erfahrung und einem großen Professional-Services-Team. Score 5 gemäß Skala 'Very strong supplier skill and large-enterprise fit'.

💡 Begründung: Als IBM-Tochter mit enormer Finanzkraft, globalem Kundenstamm und kritischer Marktposition besteht keinerlei signifikantes Lieferantenausfallrisiko. Score 5 gemäß Skala 'Very large and low-risk supplier base'.

💡 Begründung: Red Hat/IBM hat eine globale Präsenz mit lokalen Support-Organisationen, zertifizierten Partnern in nahezu allen Ländern und nachgewiesener Erfahrung in internationalen Rollouts. Score 5 gemäß Skala 'Strong worldwide rollout and support capability'.

💡 Begründung: Die Plattform ist weitgehend unabhängig von applikativen Strategieprojekten, aber Infrastrukturprojekte (Netzwerk, Storage, Security) können Schnittpunkte erzeugen. Es gibt weder starke positive Synergie noch starke negative Abhängigkeiten zu typischen Unternehmensprogrammen. Score 3 gemäß Skala 'Neutral dependency position'.

💡 Begründung: Die Plattform wurde explizit für agile und Cloud-Native-Entwicklungspraktiken konzipiert. Alle integrierten Tools (Pipelines, GitOps, Operators) fördern iterative, automatisierte Delivery. Score 5 gemäß Skala 'Very strong agile or product delivery fit'.

💡 Begründung: Die Plattform ist sehr umfangreich (ACM, ACS, Quay, ODF, Virtualization) und erfordert tiefes Know-how für initiale Konzeption und Aufbau. Bare-Metal mit Metal3/Ironic und Air-Gap-Setup erhöhen den Aufwand erheblich. Laut Skala entspricht dies 'High setup cost' = Score 2.

💡 Begründung: Das vollständige Portfolio mit zahlreichen integrierten Komponenten (ACM, ACS, Quay, ODF, Virtualization) bietet zwar viel out-of-the-box, jedoch ist der Integrationsaufwand für eine KRITIS-konforme Bare-Metal-Umgebung hoch. 'High implementation effort' = Score 2 ist angemessen.

💡 Begründung: RHEL CoreOS, Operator-gesteuerter Lifecycle und OTA-Upgrades reduzieren Day-2-Aufwand deutlich gegenüber traditionellen Ansätzen. Die Vielzahl der Komponenten und KRITIS-Compliance-Anforderungen halten den Aufwand jedoch auf moderatem Niveau. Score 3 = 'Moderate operating effort' ist passend.

💡 Begründung: Das Core-basierte Subscription-Modell von Red Hat ist bekannt dafür, bei großen Bare-Metal-Clustern kostspielig zu werden. Obwohl das Bundle (ACM, ACS, Quay, ODF) im Vergleich zu Einzellizenzen Vorteile bietet, liegt der Gesamtpreis über dem Marktschnitt. 'Teuer oder intransparent' trifft teilweise zu = Score 2.

💡 Begründung: Die Plattformkonsolidierung (VM + Container, Security, Storage, Registry in einem Bundle), Automatisierungsfeatures und reduzierter Toolchain-Overhead sprechen für starke Folgeeffizienz. OpenShift Virtualization ermöglicht zudem VMware-Ablösung. Score 4 = 'Strong efficiency benefit' ist gerechtfertigt, da die initiale Komplexität eine volle 5 verhindert.

💡 Begründung: Red Hat verfügt über ein gut dokumentiertes Support-Modell mit Hotline-Zugang und Self-Service-Portal. Die Möglichkeit zur Zusammenarbeit mit dem Kunden-eigenen 1st-Level ist gegeben, jedoch sind spezifische White-Label-1st-Level-Vereinbarungen eingeschränkt, was einen Score von 4 (Strong support model) statt 5 rechtfertigt.

💡 Begründung: Red Hat hat ein etabliertes 2nd-Level-Modell mit dedizierten Support Engineers und klaren Eskalationswegen, insbesondere im Premium-Tier mit Technical Account Manager (TAM). Dies entspricht dem Score 5 (Strong expert-backed second-level model).

💡 Begründung: Als Hersteller von OpenShift hat Red Hat direkten Zugang zu den Engineering-Teams. Der Bugfixing-Prozess ist transparent über den Red Hat Bugzilla/Jira-Tracker, und Fixes werden zeitnah als Errata veröffentlicht. Dies entspricht Score 5 (Strong engineering-backed 3rd-level process).

💡 Begründung: Red Hat erfüllt alle genannten Kriterien: strukturiertes Ticket-System mit API-Integration für Ticket-Bridges, weltweiter Support, Mehrsprachigkeit, TAM-Option und klare Einbindung des Kunden in den Prozess. Score 5 (Very strong enterprise support concept) ist gerechtfertigt.

💡 Begründung: Red Hat veröffentlicht dokumentierte Response-Time-SLAs nach Severity-Stufen, insbesondere im Premium-Support. Lösungszeiten (nicht nur Reaktionszeiten) sind weniger präzise definiert, was einen Score von 4 (Good SLA offering) statt 5 rechtfertigt.

💡 Begründung: 24/7-Abdeckung ist für kritische Fälle (Severity 1) im Premium-Tier vorhanden und global. Da nicht alle Severity-Stufen 24/7 abgedeckt werden und regionale Unterschiede existieren, wird Score 4 (Good regional coverage) vergeben statt 5.

💡 Begründung: Red Hat verfügt über eines der umfangreichsten Trainingsportfolios im Enterprise-Linux/Kubernetes-Bereich mit rollenspezifischen Kursen, Zertifizierungen, Videos, Webinaren und face-to-face-Optionen. Score 5 (Extensive training and documentation) ist klar gerechtfertigt.

💡 Begründung: RHEL CoreOS erfüllt alle Kriterien der Stufe 5: Eigenes Portfolioprodukt (nicht Drittprodukt), vollständig deklarativ via MCO, SSH technisch deaktivierbar/standardmäßig nicht genutzt, A/B-Updates via rpm-ostree produktiv nachgewiesen, und Red Hat stellt SBOMs für seine Produkte bereit. Dies entspricht der vollständigen Erfüllung der Skala-5-Kriterien.

💡 Begründung: Metal3/Ironic ist ein eigener CAPI-Provider im Red-Hat-Portfolio, BMC/IPMI-Integration ist nativ vorhanden, und der Provisionierungszyklus ist weitgehend deklarativ automatisiert. Vollständig hands-free Wipe/Reprovision ist produktiv referenziert, jedoch sind in Randfällen (z. B. bestimmte Vendor-BMC-Implementierungen) kleine manuelle Ausnahmen bekannt – daher Stufe 4 statt 5.

💡 Begründung: OVN-Kubernetes unterstützt zwar erweiterte Netzwerkfunktionen und Hardware-Offloading, ist jedoch kein BGP-natives, overlay-freies CNI mit eBPF-Dataplane. Red Hat bietet kein eigenes CNI-Produkt mit nativem eBGP und overlay-freiem Betrieb im Portfolio. Cilium (Isovalent) ist seit kurzem Teil von Cisco/Red Hat-Ökosystem, aber nicht als Red-Hat-eigenes Portfolioprodukt positioniert – daher konservativ Stufe 2.

💡 Begründung: Der integrierte Observability-Stack liefert etcd-Metriken und Alerting (Stufe 3-4-Kriterien erfüllt), jedoch fehlen dedizierte NVMe-spezifische Dashboards mit konfigurierbaren IOPS-Schwellwerten und automatischer Eskalation/Selbstheilung als explizites Portfolioprodukt. NVMe-Tuning erfolgt über Runbooks – damit entspricht dies Stufe 3.

💡 Begründung: Das Portfolio enthält alle wesentlichen Komponenten für vollständigen Air-Gap-Betrieb (Registry, OperatorHub-Mirror, OS-Image-Store, oc-mirror für Automatisierung). Stufe 5 würde einen nachgewiesenen air-gap-Compliance-Report erfordern – dieser ist bei Red Hat nicht als formales Dokument publiziert. Die Lösung ist produktiv nachgewiesen, daher Stufe 4.

💡 Begründung: Weder OpenShift noch ACM/ACS oder andere Komponenten des Platform-Plus-Portfolios beinhalten ein dediziertes Chaos-Engineering-Tool. Es gibt keine Red-Hat-eigene Lösung für kontrollierte Fehlerinjektion auf Kubernetes- oder Bare-Metal-Ebene – dies entspricht eindeutig Stufe 1 der Skala.

💡 Begründung: ODF Stretch Cluster, ACM ApplicationSets und etcd-Quorum-Design decken die wesentlichen Anforderungen ab. Referenzarchitekturen sind dokumentiert und produktiv nachgewiesen. Ein expliziter KRITIS-spezifischer Referenzkunde für Multi-Site ist nicht öffentlich nachweisbar – daher Stufe 4 statt 5.

💡 Begründung: ODF/Ceph ist ein eigenes Red-Hat-Portfolioprodukt (durch Akquisition von Red Hat/Ceph-Integration), synchrone Replikation ist konfigurierbar, und Failover ist teilautomatisiert. Gemessene Latenz-Overhead-Dokumentation für < 5 ms bei 50 ms RTT und vollautomatisches Failover < 30 s sind nicht explizit publiziert – konservativ Stufe 3.

💡 Begründung: ACS nutzt eBPF-basiertes Monitoring und verfügt über einen Enforce-Modus (Runtime Policy Enforcement). Audit-Trails sind vorhanden und BSI-Grundschutz-Mappings existieren, jedoch fehlt eine formale BSI-Anerkennung/Zertifizierung und öffentlich nachweisbare KRITIS-Referenzkunden spezifisch für §8a BSIG. Der Detect-only vs. Enforce-Modus ist verfügbar, BSI-Konformitätsdokumentation ist in Arbeit – Stufe 3 bis 4, konservativ Stufe 3.

💡 Begründung: SBOM-Generierung (Red Hat stellt SBOMs bereit), Cosign-Signaturprüfung via Quay, CVE-Scanning via ACS/Quay und Admission Controller sind im Portfolio vorhanden. Air-Gap-Betrieb mit lokalem CVE-Feed ist dokumentiert aber nicht vollautomatisch. Keine explizite KRITIS-Referenz für Supply-Chain-Security – Stufe 4 ist angemessen.

💡 Begründung: Physische Compute-Trennung, Netzwerksegmentierung und RBAC-Isolation sind im Portfolio implementierbar. ACM und ACS liefern Compliance-Reports. VLAN/VRF bis ToR-Ebene ist über OVN-Kubernetes konfigurierbar. Für Stufe 5 wäre ein automatisierter BSI-spezifischer Compliance-Report und ein KRITIS-Referenzkunde erforderlich – beides nicht explizit publiziert, daher Stufe 4.

💡 Begründung: ArgoCD ist als Red-Hat-eigenes Portfolioprodukt (OpenShift GitOps Operator) positioniert, Drift-Erkennung und automatische Korrektur sind nativ, air-gap-Betrieb ist mit Konfigurationsaufwand möglich. Die Drift-Erkennung liegt typisch unter 3 Minuten, nicht garantiert unter 60 Sekunden. Kein expliziter KRITIS-Referenzkunde publiziert – Stufe 4 ist angemessen.

💡 Begründung: OpenShift erfüllt den CAPI-basierten deklarativen Lifecycle nahezu vollständig aus eigenem Portfolio, jedoch sind in bestimmten Szenarien (z.B. initiale BMH-Registrierung oder Fehlerdiagnose) dokumentierte Ausnahmen bekannt, was einen Score von 4 statt 5 rechtfertigt. Rolling Upgrades mit Rollback-Fähigkeit sind vorhanden.

💡 Begründung: Der Stack ist weitgehend aus eigenem Portfolio vorhanden und air-gap-fähig, IPMI/SMART-Integration erfolgt über Exporter (nicht nativ), und die Korrelations-UI ist teilweise vereinheitlicht in der OpenShift-Console. Dies entspricht Score 4 gemäß Skala.

💡 Begründung: ACS liefert kontinuierliches CIS K8s L2 Scanning, automatisches Reporting und BSI-Export-Möglichkeit aus eigenem Portfolio. SIEM-Integration ist konfigurierbar. Score 4 ist angemessen, da der vollständige BSI-Grundschutz-Export und automatische SIEM-Integration konfigurationsaufwendig sind und ein expliziter KRITIS-Audit-Referenznachweis konservativ bewertet wird.

💡 Begründung: Red Hat besitzt kein eigenes Secrets-Management-Produkt mit nativer PKCS#11 HSM-Integration. Die HSM-Integration erfolgt über Drittprodukte (Vault, CyberArk) via CSI Driver. etcd-Encryption ist manuell konfigurierbar. Dies entspricht Score 3 der Skala (HSM-Integration über Plugin, etcd-Encryption manuell).

💡 Begründung: Das Portfolio deckt >70% der Kernfunktionen ab, jedoch fehlen Chaos-Engineering und dediziertes HSM-Secrets-Management als eigene Produkte. BGP-Fähigkeiten via OVN-Kubernetes sind vorhanden, aber für vollständiges ToR-BGP-Peering sind Zusatzkonfigurationen nötig. Score 3 ist konservativ aber angemessen für die Lücken.

💡 Begründung: Red Hat hat einen dokumentierten, koordinierten PSIRT-Prozess mit bekannten SLA-Vorgaben für kritische CVEs. Die < 72h-SLA für CVSS ≥ 9.0 ist in Red Hat-Dokumentationen referenziert. Air-Gap-Patch-Distribution erfordert manuelle Schritte (Mirror-Update). Score 4 entspricht dem dokumentierten Prozess mit air-gap-Distribution mit manuellem Schritt.

💡 Begründung: Red Hat hat KRITIS-Erfahrung und deutsche Ingenieure, aber ein schriftlich zugesichertes dediziertes KRITIS-Team mit Ü2-Überprüfung für alle Support-Ingenieure ist nicht öffentlich dokumentiert. Score 3 (Sicherheitsüberprüfung auf Anfrage, KRITIS-Erfahrung im Team vorhanden, kein dediziertes Team) ist konservativ und angemessen.

💡 Begründung: Öffentlich nachweisbare, spezifische Referenzinstallationen bei europäischen Energieversorgern/ÜNBs mit Bare-Metal K8s air-gapped sind nicht explizit öffentlich dokumentiert. Red Hat hat KRITIS-Erfahrung, aber der Nachweis auf Energiesektor/ÜNB-Ebene ist unklar. Score 3 (Energieversorger-Referenz möglich, aber nicht klar Bare-Metal air-gapped verifizierbar) ist konservativ angemessen.

💡 Begründung: OVN-Kubernetes unterstützt BGP und BFD, aber die nahtlose end-to-end-Automatisierung inklusive Switch-seitiger Konfigurationsvorlagen für mehrere Hersteller ist nicht als Portfolio-Feature dokumentiert. Switch-Integration erfordert manuelle Schritte. Score 3 gemäß Skala (BGP automatisierbar, BFD vorhanden, Switch-Seite erfordert manuelle Konfiguration).

💡 Begründung: ACS liefert gutes Alerting und Ereigniskorrelation, aber ein automatisierter NIS-2-konformer Klassifikations- und Export-Workflow (STIX/TAXII, MISP) aus eigenem Portfolio ist nicht dokumentiert. Die Meldeketten-Integration erfordert kundenspezifische Eigenentwicklung. Score 2 ist angemessen gemäß Skala.

💡 Begründung: OpenShift dokumentiert etcd-Recovery-Prozesse, jedoch ist die vollautomatische etcd-Member-Entfernung und Wiederaufnahme ohne manuelle Intervention nicht als vollständig automatisierter Prozess im Portfolio beschrieben. Recovery erfordert typischerweise mehrere manuelle Schritte. Score 3 (automatisierte Erkennung, Recovery erfordert mehrere manuelle Schritte, dokumentierter Prozess) ist angemessen.

💡 Begründung: Die Kombination aus ACS und OpenShift Service Mesh liefert identitätsbasierte L4/L7-Segmentierung aus dem eigenen Portfolio. L3 bleibt teilweise IP-basiert via OVN-Kubernetes NetworkPolicies. GitOps-Integration ist vorhanden. Score 4 entspricht identitätsbasierter Segmentierung auf L4/L7 mit L3 noch IP-basiert und GitOps-Integration.

💡 Begründung: Metal3/Ironic + Cluster API bieten deklaratives, idempotentes Reprovisioning. RHEL CoreOS unterstützt Secure Boot und signierte Images. Die Cluster-Reintegration ist durch den Machine Config Operator und BareMetalHost-Controller weitgehend automatisiert. Ein Score von 5 würde vollständige Nachweisbarkeit der Idempotenz in unter 15 Minuten ohne jeden manuellen Schritt erfordern – hier gibt es in Produktionsumgebungen gelegentlich minimale Eingriffe, daher Score 4.

💡 Begründung: Red Hat referenziert BSI IT-Grundschutz und hat Erfahrung mit KRITIS-Projekten, liefert aber kein offiziell durch BSI-zertifizierten Auditor geprüftes Grundschutz-Profil. Das vorhandene Mapping deckt Kernbausteine ab, ist aber nicht vollständig und nicht extern zertifiziert, was Score 3 entspricht (partielles Mapping, Lücken müssen kundenseitig geschlossen werden).

💡 Begründung: ODF/Ceph Stretch Cluster ermöglicht synchrone Replikation, was theoretisch RPO=0 erlaubt. Jedoch fehlen öffentlich dokumentierte Benchmarks aus Bare-Metal-Produktionsumgebungen mit konkreten RTO-Werten. Die verfügbaren Daten stammen typischerweise aus Lab-Umgebungen. Score 3 ist konservativ angemessen: Werte aus virtualisierten/Lab-Umgebungen extrapoliert, RTO<30 Minuten plausibel aber nicht produktionsvalidiert.

💡 Begründung: ArgoCD unterstützt GPG-Signaturverifikation für Commits, aber die Enforcement auf Controller-Ebene ist konfigurierbar, nicht standardmäßig erzwungen. Ein eigenes Git-Repository-Produkt fehlt im Red-Hat-Portfolio (Gitea/GitLab sind Drittprodukte). Das 4-Augen-Prinzip ist primär prozessual umsetzbar. Dies entspricht Score 3: Commit-Signing möglich aber nicht zwingend controller-seitig durchgesetzt, 4-Augen nur prozessual.

💡 Begründung: OpenShift's Cluster Version Operator koordiniert Upgrades über alle Schichten mit einer offiziellen Upgrade-Kompatibilitätsgraph. Pre-Upgrade-Checks sind automatisiert. Der Rollback-Mechanismus erfordert in einigen Szenarien (z.B. nach abgeschlossenen Teilupgrades von ODF) minimale manuelle Eingriffe. Score 4 ist angemessen: Koordiniertes Upgrade mit Kompatibilitätsmatrix und Health-Checks, Rollback mit minimalem manuellem Eingriff.

💡 Begründung: RHEL CoreOS bietet Secure Boot und grundlegende TPM-Unterstützung, aber keine automatisierte PCR-Sollwert-Verwaltung oder Remote Attestierung als erzwungene Cluster-Aufnahme-Bedingung aus dem eigenen Portfolio. Red Hat hat Keylime als Open-Source-Projekt, aber dies ist nicht nativ in OpenShift's Provisioning-Workflow integriert. Score 2: Secure Boot vorhanden, aber keine TPM-basierte Remote Attestierung als Kernfeature.

💡 Begründung: Der OpenShift Observability Stack deckt Kubernetes- und grundlegende Hardware-Metriken ab. Redfish/IPMI-Integration ist über den Bare Metal Event Relay Operator möglich. Jedoch sind NVMe SMART-spezifische und detaillierte NIC-Fehlerstatistik-Exporter nicht standardmäßig im Portfolio, und ML-basiertes Predictive Maintenance fehlt vollständig. Score 3: IPMI/Redfish verfügbar, weitere Metriken erfordern zusätzliche nicht-portfolio Exporter.

💡 Begründung: OpenShift hat starke RBAC- und Audit-Logging-Fähigkeiten, aber kein dediziertes PAM-Produkt mit JIT-Zugriff, Genehmigungsworkflow und Session Recording im Portfolio. Die Beschreibung erwähnt Integration mit CyberArk/HashiCorp Vault, aber diese sind Drittprodukte. Score 2: Grundlegendes Zugriffsmanagement ohne JIT, Session Recording nur mit externer Komponente.

💡 Begründung: RHEL hat in der Vergangenheit CC EAL4+ erreicht, aber aktuelle OpenShift-spezifische Komponentenzertifizierungen (CNI, Admission Controller) sind nicht explizit dokumentiert. Red Hat/IBM ist ISO 27001-zertifiziert. Dies entspricht Score 3: ISO 27001 vorhanden, mögliche Komponentenzertifizierungen ohne klar kommunizierte Zeitlinie für OpenShift-spezifische Zertifizierungen.

💡 Begründung: Red Hat/IBM publiziert SBOMs und hat Transparenz-Initiativen (Red Hat Product Security), jedoch fehlt ein explizit dokumentiertes, kontinuierliches geografisches Lieferketten-Monitoring mit automatisierten Alerts gemäß BSI-Drittlands-Kategorisierung. SBOM-Analyse gibt Hinweise, aber systematisches Drittlands-Monitoring fehlt. Score 3 ist konservativ angemessen.

💡 Begründung: Die lokale OpenShift Control Plane, ArgoCD-Reconciliation aus lokalem Cache, Quay, ODF und Prometheus funktionieren vollständig ohne WAN. ACM-Funktionen (zentrales Policy-Enforcement) sind degradiert aber beeinträchtigen nicht den lokalen Cluster-Betrieb. Das Wiedervereinigungsverfahren nach WAN-Wiederherstellung ist dokumentiert. Score 4: Kernfunktionen vollständig autonom, einige Management-Funktionen degradiert aber nicht blockierend.

💡 Begründung: OpenShift hat CoreDNS (lokaler DNS-Fallback), interne CA-Rotation, und htpasswd als lokalen Identity-Fallback. NTP-Fallback auf GPS/Stratum-1 ist jedoch externe Hardware, nicht im Portfolio. PKI-Rotation ohne externe CA ist konfigurierbar aber nicht standardmäßig aktiviert. Nicht alle Szenarien sind durch eigene Portfolio-Produkte vollständig abgedeckt oder regelmäßig getestet. Score 3: Fallbacks für die meisten Abhängigkeiten vorhanden, einzelne erfordern manuelle Eingriffe oder Dritttools.

💡 Begründung: Gemäß Skala entspricht Score 2 'nur Standard-Log-Archivierung ohne kryptografische Sicherung gegen Manipulation; keine Langzeitarchivierungsstrategie'. Red Hat bietet keinen Portfolio-eigenen TR-ESOR-konformen Archivierungsdienst. Loki und der Audit-Log-Stack erfüllen keine kryptografische Verkettung im Sinne von Merkle-Trees, keine qualifizierten TSA-Zeitstempel nach eIDAS und keinen echten WORM-Storage als Eigenprodukt. TR-ESOR-Konformität muss vollständig über Drittanbieter (z.B. spezialisierte Archivlösungen wie IBM Guardium oder externe ESOR-Systeme) hergestellt werden. Score 1 wäre zu streng, da zumindest unveränderliche Log-Strukturen und Audit-APIs vorhanden sind, aber Score 3 wäre zu hoch, da keine explizite manipulationssichere Archivierung als Eigenkomponente existiert.

💡 Begründung: Metal3 mit Ironic ist das Eigenprodukt von Red Hat/OpenShift für Bare-Metal-OOB-Management. Ironic unterstützt explizit Redfish (DMTF-Standard) und IPMI/DCMI nativ und ist herstellerunabhängig. Dokumentierte Unterstützung existiert für iDRAC (Dell), iLO (HPE) und generische IPMI/Redfish-Implementierungen (AMI, Supermicro). Die CAPI-Integration via Cluster API Provider for Metal3 (CAPM3) ist nativ vorhanden. Automated Provisioning, PXE-Boot-Forcing, Power-Cycle und Clean/Wipe-Operationen sind vollständig deklarativ über BareMetalHost-Custom-Resources steuerbar. Dies entspricht Score 5 der Skala.

💡 Begründung: OVN-Kubernetes unterstützt grundlegende L3/L4-Isolation und kann OT-Protokolle wie IEC 60870-5-104 (TCP-basiert) über NetworkPolicies kontrollieren. Layer-2-Multicast für GOOSE ist jedoch ein fundamentales Problem für overlay-basierte CNIs: GOOSE operiert auf Ethernet-Multicast-Ebene (Layer 2) was OVN-Kubernetes standardmäßig nicht transparent durchleitet – hier sind manuelle Konfigurationen auf Host-Netzwerkebene notwendig. Eine explizite OT-Protokoll-Validierung oder dokumentierte Referenzarchitektur für Energieversorger existiert nicht öffentlich. Score 3 entspricht der Skala: 'Grundlegende L3/L4-Isolation möglich; Layer-2-Multicast-Handling erfordert manuelle Netzwerkkonfiguration außerhalb des CNI; keine dokumentierte OT-Referenzarchitektur'.

💡 Begründung: Red Hat (IBM) bietet als Open-Source-Unternehmen den Quellcode der meisten Kernkomponenten öffentlich (github.com/openshift, github.com/metal3-io, github.com/ceph), was de-facto eine stärkere Absicherung als Escrow darstellt. Reproduzierbare Builds sind für RHEL/CoreOS konzeptionell vorhanden aber nicht formal nach Reproducible-Builds-Spezifikation zertifiziert. Einzelne proprietäre Elemente (z.B. spezifische Red-Hat-Operator-Logik, ACS/StackRox-Teile) sind nicht vollständig Open-Source. Formale EU-Escrow-Verträge sind nicht Teil des Standardangebots, könnten aber vertraglich vereinbart werden. Score 4 ist angemessen: Open-Source als starke Absicherung, aber keine formale Escrow-Zertifizierung und einzelne proprietäre Komponenten ohne vollständige Abdeckung.

💡 Begründung: RHEL CoreOS gilt branchenweit als Best-in-Class für immutable OS auf Kubernetes: atomare Updates, automatisches Rollback, operator-gesteuertes Lifecycle-Management – alle Kriterien der Score-5-Definition sind erfüllt.

💡 Begründung: Metal3/Ironic + Cluster API ist eine ausgereifte, produktionserprobte Kombination, die alle genannten Anforderungen (Hardware-Inventar, IPMI/Redfish, Netzwerk, vollautomatische API-Steuerung) out-of-the-box abdeckt – Score 5 ist gerechtfertigt.

💡 Begründung: OpenShift bietet mit CAPI-Integration, Hive und dem nativen Cluster-Upgrade-Operator eine ausgereifte, deklarative Lösung für den gesamten Cluster-Lifecycle – entspricht der Best-in-Class-Definition (Score 5).

💡 Begründung: ACM ist eine dedizierte, ausgereifte Multi-Cluster-Management-Plattform mit umfassendem Policy-Framework (Governance), Observability und Fleet-Management – alle Score-5-Kriterien sind erfüllt.

💡 Begründung: Kombination aus nativem ArgoCD-Operator (OpenShift GitOps) und ACM-GitOps-Integration erfüllt alle Anforderungen an natives, produktionsreifes GitOps – Score 5 gerechtfertigt.

💡 Begründung: Das Zusammenspiel von Quay (Signierung), ACS (Policy-Enforcement) und nativem OpenShift-Admission-Controller ergibt eine vollständige, ausgereifte Lösung – Score 5 ist gerechtfertigt.

💡 Begründung: ACS/StackRox ist eines der ausgereiftesten Kubernetes-nativen Runtime-Security-Produkte am Markt und erfüllt alle genannten Kriterien (Baselines, Anomalieerkennung, Schwachstellen, Bedrohungsabwehr) – Score 5.

💡 Begründung: Quay+Clair für Registry-Scanning und ACS für Deployment-/Runtime-Scanning ergeben eine mehrschichtige, vollständig integrierte Lösung – alle Anforderungen sind Best-in-Class erfüllt (Score 5).

💡 Begründung: OVN-Kubernetes erfüllt NetworkPolicy und Egress-Control sehr gut, aber native Layer-7-Policy-Fähigkeiten sind nicht vollständig out-of-the-box vorhanden (erfordern Service Mesh als Add-on), daher Score 4 statt 5.

💡 Begründung: ODF Stretch Cluster ist produktionsreif und bietet Geo-Redundanz, aber die Konfiguration ist komplex und auf 2-Standort-Metro-Szenarien mit Latenzlimits beschränkt. Score 4: gut und übertrifft Mindestanforderung, aber nicht ohne Einschränkungen als vollständig Best-in-Class zu werten.

💡 Begründung: OpenShift Virtualization ist eine ausgereifte Lösung für VM-on-Kubernetes, jedoch noch nicht ganz auf dem Reifegrad etablierter Hypervisoren für alle Enterprise-VM-Szenarien. Score 4: gut, übertrifft Mindestanforderung, mit bekannten Fortschritten in 4.15.

💡 Begründung: Red Hat ist Marktführer beim Air-Gap-Support für Kubernetes-Plattformen mit durchgängig dokumentierten und getesteten Offline-Workflows für alle Komponenten – Score 5 (Best-in-Class) ist eindeutig gerechtfertigt.

💡 Begründung: OpenShift ist eine der wenigen Enterprise-Kubernetes-Plattformen mit echtem, durchgesetztem FIPS-Modus auf OS-Ebene (RHEL CoreOS) und validiertem Cryptomodul-Stack. FIPS-Aktivierung ist ein First-Class-Feature seit Jahren, gut dokumentiert und in Behördenumgebungen (US FedRAMP, NATO) erprobt. Score 5 ist gerechtfertigt.

💡 Begründung: Die Kombination aus ACS-Compliance-Dashboards (automatisierte Scans gegen CIS, STIG, PCI-DSS etc.), OpenShifts gehärteten Defaults und Red Hats dokumentierter BSI/KRITIS-Erfahrung liefert ein Best-in-Class-Angebot. Out-of-the-box Compliance-Reporting ohne manuelle Drittkomponenten rechtfertigt Score 5.

💡 Begründung: Quay bietet HA-Setup, Geo-Replication, Image-Mirroring und dedizierte Air-Gap-Tooling (oc-mirror CLI, disconnected OperatorHub). Dies ist ein durchgängig reifes, seit Jahren in Produktion bewährtes Feature – Best-in-Class für diese Anforderung, Score 5.

💡 Begründung: Der integrierte Stack deckt alle vier Observability-Säulen (Metrics, Logs, Alerts, Dashboards) ab und wird vollständig operator-managed bereitgestellt. Seit OCP 4.11+ auch User-Workload-Monitoring und Loki als Log-Backend integriert. Best-in-Class-Erfüllung ohne externe Abhängigkeiten, Score 5.

💡 Begründung: Tekton-basierte Pipelines, S2I-Builds und GitOps (ArgoCD) sind nativ integriert und seit Jahren produktionsreif. Die Kombination aus Pipeline-Engine und Image-Build-Services innerhalb der Plattform ohne externe Tools ist Best-in-Class. Score 5.

💡 Begründung: OpenShift hat seit Version 3.x branchenführende Multi-Tenancy-Konzepte: SCCs (Security Context Constraints) als OS-level Isolation, OVN-basierte Netzwerksegmentierung, RBAC auf Namespace- und Cluster-Ebene und Ressourcenquoten. Best-in-Class für Enterprise-Multi-Tenancy, Score 5.

💡 Begründung: Red Hat hat eine etablierte deutsche Support-Organisation, langjährige KRITIS-Referenzen und dokumentierte BSI-Grundschutz-Erfahrung. Enterprise-Support mit Premium-SLAs (1h Response für Critical) ist Standard. Best-in-Class für diese Anforderung im deutschen Markt, Score 5.

💡 Begründung: Die Kombination aus ODF (Ceph HCI-Storage), OpenShift Virtualization (KubeVirt), OVN-Networking und Metal3-Provisionierung auf Bare-Metal ist eine reife, produktionserprobte HCI-Architektur. VMs und Container laufen auf derselben Infrastruktur mit gemeinsam genutztem Storage-Backend – Best-in-Class, Score 5.

💡 Begründung: Rancher Prime stellt vollständige, dokumentierte REST-APIs bereit, alle UI-Funktionen sind über die API zugänglich, und gängige Integrationen (z.B. Terraform Provider, kubectl, Helm, ArgoCD) sind vorhanden. Out-of-the-box-Konnektoren für Middleware wie PI/EAI/EDI-Manager sind jedoch nicht im Kern-Portfolio enthalten, was den Score auf 4 statt 5 begrenzt.

💡 Begründung: Die Plattform bietet Basis-Monitoring über Prometheus/Grafana-Integration, Health-Endpoints und Logging, was der Skala-Stufe 3 entspricht. Ein starkes, dediziertes Interface-Monitoring mit automatischer Diagnose ist nicht out-of-the-box vorhanden – zusätzliche Tools wie externe APM-Lösungen wären erforderlich, um Stufe 4 oder 5 zu erreichen.

💡 Begründung: Das System unterstützt custom Rollen auf mehreren Ebenen (global, Cluster, Projekt/Namespace), was über statisches RBAC hinausgeht. Ein vollständiges pfad-basiertes ABAC wie in Score 5 beschrieben ist nicht nativ vorhanden, daher Score 4 für flexibles RBAC ohne granulare Pfad-Filterung.

💡 Begründung: Die native Unterstützung umfasst LDAP, SAML und OIDC für Authentifizierung, jedoch kein natives SCIM für automatisiertes User/Group-Lifecycle-Management. Dies entspricht Score 3 (Legacy Auth & Basic Provisioning via SAML/LDAP).

💡 Begründung: Rancher bietet in der UI konfigurierbare Auth-Provider für OIDC und SAML, inklusive Azure AD, ohne dass der Vendor eingreifen muss. Dies erfüllt vollständig Score 5 (Self-Service für OIDC & SAML).

💡 Begründung: Die Kombination aus Cluster-Isolation, Projekten als Top-Level-Einheiten mit dedizierten Benutzerrollen und Ressourcenquoten entspricht Score 5 (Full Logical Multi-Tenancy). Harvester ergänzt zusätzlich VM-Level-Isolation.

💡 Begründung: Die externe Datenbank ist optional, nicht zwingend erforderlich – ein Embedded-Betrieb ist möglich und wird für kleinere Deployments genutzt. Dies entspricht Score 3 (Optional External DB). Für Production wird externe DB empfohlen, aber nicht erzwungen.

💡 Begründung: Longhorn unterstützt S3-kompatible Backup-Targets nativ, was Azure Blob und GCS über S3-kompatible Gateways einschließt. Native direkte Integration für alle drei großen Provider ohne Gateway ist nicht vollständig dokumentiert, daher Score 4.

💡 Begründung: Die verfügbaren Cleanup-Funktionen in Longhorn und Rancher sind eher zeitplanbasiert (scheduled cleanup) als vollständig policy-getrieben mit Metadaten-Kriterien. Dies entspricht Score 3 (Basic Scheduled Cleanup).

💡 Begründung: Das Produkt ist stark auf On-Premise ausgerichtet (Kernstärke), kann auf Kubernetes/Containern laufen, aber kein SaaS-Angebot existiert und PaaS-Support ist nicht der primäre Fokus. Score 3 (Strong On-Premise with Basic PaaS/Container Support) trifft am besten zu.

💡 Begründung: Der kombinierte Stack mit HCI (Harvester), verteiltem Storage (Longhorn) und Security (NeuVector) benötigt spürbar Ressourcen, besonders für Produktionsumgebungen. Management-Komponenten sind containerisiert, der Gesamt-Footprint ist jedoch adäquat aber ressourcenintensiv – Score 3.

💡 Begründung: RKE2 hat einen einfachen Installer, Rancher wird per Helm deployt, und Fleet/NeuVector haben klare Installationspfade. Dies entspricht Score 4 (Scripted Installation) – nicht vollautomatisiert per Single-Command, aber gut skriptierbar.

💡 Begründung: Fleet bietet asynchrone Synchronisation und zentrales Management für Multi-Location-Deployments. Ein vollständiges aktiv-aktives Federated-Repository-Modell mit Echtzeit-Metadaten-Sync ist nicht dokumentiert, daher Score 4 (Asynchronous Replication/Sync).

💡 Begründung: Die Architektur basiert auf bewährten, performanten Komponenten (RKE2, etcd, Longhorn mit verteiltem Storage). Für die meisten Enterprise-Szenarien ist die Performance gut, größere Deployments erfordern ggf. Tuning – Score 4 ist angemessen.

💡 Begründung: Rancher Prime bietet bewährtes Multi-Cluster-Management, Fleet-basiertes Deployment für Tausende Cluster und RKE2-native HA-Unterstützung. Für Bare-Metal-Umgebungen ist horizontale Skalierung gut unterstützt, jedoch erfordert Bare-Metal-Autoscaling (z.B. via Cluster API) manuelle Konfiguration. Dies entspricht Score 4: Good concurrency support für most enterprise loads.

💡 Begründung: K3s als Edge-Kubernetes, dezentrale Cluster-Architektur und Air-Gap-Support bieten gute Mechanismen für verteilte/Remote-Standorte. Fleet ermöglicht asynchrones GitOps, das Latenz toleriert. Kein nativer CDN oder Content-Caching für UI-Assets, daher Score 4 statt 5.

💡 Begründung: Grundlegende Konfiguration (Cluster, RBAC, Netzwerkpolicies via UI) ist no-code möglich. Viele operative Anpassungen (Helm Values, NeuVector CRDs, Longhorn Storage-Policies) erfordern jedoch YAML/Helm-Kenntnisse. Dies entspricht Score 3: Basic no-code für standard settings, advanced needs require coding.

💡 Begründung: Vollständige Kubernetes-native API, Rancher Management API, NeuVector REST API und Helm/Operator-Framework bieten starkes Coding-Extensibility-Modell. Dokumentation und Support-Grenzen für Custom Code sind klar definiert. Leichte Abstriche wegen fehlender dedizierter Plugin-SDK für UI-Erweiterungen, daher Score 4.

💡 Begründung: Reifes RBAC-Modell mit externer Identity-Integration (LDAP, OIDC, GitHub, etc.) und Projekt/Namespace-basierter Governance ist gut für Offshore-Collaboration. Kein explizites 'Guest/External-User'-Konzept wie in SaaS-Plattformen, aber operativ gut umsetzbar. Score 4 ist angemessen.

💡 Begründung: Kubernetes-native Extension-Punkte (Admission Webhooks, CRDs, Operators), Fleet-Hooks und Rancher API bieten starke Erweiterbarkeit. Ein dediziertes UI-Plugin-Framework ist vorhanden (Rancher Extensions seit v2.7), aber noch weniger ausgereift als enterprise Plugin-Ökosysteme. Score 4 ist gerechtfertigt.

💡 Begründung: Fleet als GitOps-Engine ermöglicht konsistente Konfigurationsverteilung, Rancher-UI bietet zentrales Control-Panel für Policies. Longhorn und NeuVector haben eigene Management-Interfaces, was leichte Fragmentierung erzeugt. Insgesamt aber stark, daher Score 4.

💡 Begründung: RKE2, Rancher, Longhorn, NeuVector (nach Akquisition open-sourced), K3s und Harvester sind alle auf GitHub verfügbar und aktiv als Open-Source-Projekte gepflegt. Vollständige Code-Transparenz und Modifizierbarkeit entspricht klar Score 5.

💡 Begründung: Regelmäßige Releases, gut dokumentierte Upgrade-Guides (RKE2 Minor/Patch Upgrades, Rancher Server Upgrades), CVE-Response und klare Lifecycle-Policies sprechen für Score 4. Regression-Testing auf Bare-Metal erfordert kundenseitige Validierung, was 5 verhindert.

💡 Begründung: Starke HA-Architektur auf allen Schichten (OS, Kubernetes, Storage, Management), Longhorn-Snapshots und S3-Backups sowie etcd-Backup-Integration sprechen für Score 4. Kein vollständig automatisiertes Disaster-Recovery ohne manuelle Konfiguration, was Score 5 verhindert.

💡 Begründung: Rolling-Update-Mechanismen auf allen Stack-Ebenen (OS: transaktional, Kubernetes: rolling node drain/upgrade, Storage: Longhorn rolling) ermöglichen Low-Downtime-Upgrades in empfohlener Architektur. Komplexe Koordination mehrerer Komponenten verhindert Score 5 (near-zero downtime as standard). Score 4 ist angemessen.

💡 Begründung: Bei einem On-Premise-Produkt gibt es per Definition keine Provider-seitige Availability-SLA für die laufende Infrastruktur. SUSE bietet Support-SLAs (Response-Zeiten), aber keine Uptime-Garantien. Dies entspricht Score 2: Limited formal SLA relevance for typical deployment model.

💡 Begründung: Die Rancher-UI vereinfacht viele Kubernetes-Operationen, ist jedoch kein Low-Code-Tool – neue Nutzer benötigen Schulung und Dokumentation für tägliche Aufgaben. Dies entspricht Score 3 ('Acceptable; some training/documentation needed for daily tasks').

💡 Begründung: Die Integration mehrerer Akquisitionsprodukte (NeuVector, Harvester, Longhorn) führt zu erkennbaren UX-Inkonsistenzen zwischen den Modulen. Anpassungsoptionen für Enterprise-Branding sind vorhanden, aber limitiert. Score 3 ('Generally consistent but with limited adaptation options') ist angemessen.

💡 Begründung: Es gibt Wizards für häufige Aufgaben, aber kontextuelle In-Product-Hilfe und geführte Komplexoperationen (z.B. Air-Gap-Setup) sind primär dokumentationsgetrieben. Score 3 ('Basic documentation-driven guidance, limited in-product assistance') trifft zu.

💡 Begründung: Admin-Tasks sind gut abgebildet, aber Developer-Workflows (z.B. Artifact-Browse, Self-Service-Publikation) sind nicht primärer Fokus dieser Plattform. Für Enterprise-Admin-Workflows ist Rancher stark, für gemischte Teams gibt es Reibung. Score 3 ('Adequate fit with some friction in common tasks').

💡 Begründung: Für Power-User gibt es keine bekannte umfangreiche Keyboard-Shortcut-Unterstützung oder High-Productivity-Navigation. Grundlegende Filter und Suche sind vorhanden, aber keine erweiterten Produktivitäts-Features. Score 2 ('Limited productivity support') ist konservativ angemessen.

💡 Begründung: Die Plattform fokussiert auf rollenbasierte Zugriffskontrolle statt auf persönliche UX-Anpassung. End-User-Personalisierung (Theme, Layout, Widgets) ist nicht als Stärke bekannt. Score 2 ('Limited personalization options') ist realistisch.

💡 Begründung: Rancher unterstützt bekanntermaßen mehrere Sprachen in der UI, aber die Tiefe der Lokalisierung (z.B. vollständige Übersetzungen aller Module, Locale-Controls) variiert. Score 3 ('Basic localization support') ist angemessen, da keine vollständige Enterprise-Lokalisierung mit allen Teilprodukten garantiert ist.

💡 Begründung: Es liegen keine bekannten expliziten Accessibility-Zertifizierungen oder starken Keyboard-Navigation-Features für Rancher Prime vor. Grundlegende Browser-Accessibility ist gegeben, aber kein gezieltes Inclusive-Design-Programm ist dokumentiert. Score 2 ('Limited support for inclusive interaction') konservativ angemessen.

💡 Begründung: Die Anforderung adressiert Datenverwaltungskonzepte (Single Source of Truth, MDS-Integration), die nicht im Kernfokus von Rancher Prime liegen. Während GitOps-Mechanismen Konfigurationskonsistenz ermöglichen, fehlen dedizierte MDM- oder Datenreplikations-Vermeidungsmechanismen. Teilweise Konformität durch Kubernetes-API-Ansätze, aber erhebliche Lücken bei der Anforderungserfüllung im klassischen Sinne – daher Score 3.

💡 Begründung: Da das Produkt als On-Premise-Lösung konzipiert ist, entfällt die Abhängigkeit von Vendor-seitigen Cloud-Standorten vollständig – der Kunde wählt selbst. Dies erfüllt die EU-Standortanforderung ideal. Einschränkung: Der Vendor selbst bietet keine eigene managed Cloud-Infrastruktur auf bevorzugten Hyperscalern als Kernprodukt an, daher kein voller Score 5 im Sinne der Frage nach Vendor-Cloud-Infrastruktur in relevanten Ländern.

💡 Begründung: RKE2 bietet FIPS 140-2-konformen nativen Modus, etcd-Verschlüsselung at rest, TLS für alle Cluster-Kommunikation, und NeuVector sichert Layer-7-Netzwerkverkehr. Longhorn unterstützt Volume-Verschlüsselung. Die Konfiguration ist jedoch teils deployment-abhängig und erfordert kundenseitige Aktivierung einzelner Features, daher Score 4 statt 5.

💡 Begründung: Die On-Premise-Natur reduziert das DSGVO-Risiko durch fehlenden Vendor-Datenzugriff erheblich. Jedoch fehlen dedizierte GDPR-Features (strukturierte Datenlöschung, Datensubjektanfragen, explizite BDSG-Compliance-Nachweise für die Software selbst). Die grundlegende Compliance ist möglich, aber Governance-Nachweise und dedizierte Tools sind begrenzt – daher Score 3.

💡 Begründung: SUSE als etabliertes Enterprise-Unternehmen hat ISO 27001-Deckung, jedoch ist die Zertifizierungslage speziell für das Produkt Rancher Prime als On-Premise-Software (nicht Managed Service) nur indirekt relevant. Die Nachweislage für produktspezifische Zertifizierungen ist nicht vollständig transparent dokumentiert, daher konservativ Score 3.

💡 Begründung: Kubernetes-native APIs, Rancher-eigene REST APIs, Longhorn-Snapshot/Backup-Funktionen und GitOps-Integration ermöglichen starke Export-/Import-Kapazitäten. Excel-artige Upload-Funktionen für Endnutzer fehlen naturgemäß als Kubernetes-Plattform, aber operative Tooling-Unterstützung ist stark. Score 4 aufgrund der fehlenden benutzerfreundlichen Massenänderungs-UI-Funktionen.

💡 Begründung: Das Portfolio ist zwar Open-Source-basiert, aber die spezifischen Integrationen (SLE Micro A/B-Schema, Harvester HCI, proprietäre NeuVector-Policies) erzeugen moderate Lock-in-Effekte. Ein Wechsel erfordert OS-Migration, CNI-Rekonfiguration und Policy-Export. Score 3 (Moderate lock-in) ist angemessen.

💡 Begründung: SUSE ist ein börsenkotiertes Unternehmen mit mehreren tausend Mitarbeitern und einem dedizierten Engineering-Team für Rancher/RKE2/NeuVector. Die Akquisitionen wurden erfolgreich integriert. Score 4 (Strong team continuity and proven delivery) ist vertretbar.

💡 Begründung: Bare-Metal Air-Gap Deployments mit vollständigem Stack sind inherent komplexer als Cloud-basierte Lösungen. Obwohl Tooling vorhanden ist, ist der Onboarding-Aufwand signifikant. Score 3 (Moderate lead time) spiegelt dies angemessen wider.

💡 Begründung: SUSE hat eine lange Enterprise-Geschichte (SUSE Linux Enterprise) und hat durch Rancher Labs signifikante Kubernetes-Expertise aufgebaut. Für große Unternehmen sind Referenzen vorhanden. Score 4 (Strong supplier capability) ist angemessen, da spezifische Lücken im Consulting-Bereich je nach Region möglich sind.

💡 Begründung: SUSE ist ein etablierter Anbieter mit stabiler Marktposition im Enterprise-Linux-Segment, börsennotiert und mit breiter Kundenbasis. Kleiner als Red Hat/IBM, aber deutlich über dem Schwellenwert für signifikante Kontinuitätsrisiken. Score 4 (Large and credible supplier base) ist angemessen.

💡 Begründung: SUSE hat eine langjährige globale Präsenz durch SLE und Rancher. Direkte Support-Teams in allen Hauptregionen vorhanden. Score 4 (Good multi-region capability) ist korrekt, da keine Schwächen in Kernmärkten bekannt sind, aber die Tiefe variiert regional.

💡 Begründung: Kubernetes-Plattformen sind typischerweise infrastrukturelle Enabler ohne starke direkte Projektabhängigkeiten. Weder starke positive Synergie noch negative Blockaden zu typischen Standardprogrammen sind generisch erkennbar. Score 3 (Neutral dependency position) ist korrekt.

💡 Begründung: SUSE/Rancher operiert als Open-Source-First-Unternehmen mit öffentlichen GitHub-Repositories, Community-Sprints und klar getakteten Minor/Major-Releases. GitOps-Unterstützung im Produkt selbst zeigt hohe Affinität zu modernen agilen Delivery-Methoden. Score 5 (Very strong agile or product delivery fit) ist gerechtfertigt.

💡 Begründung: Bare-Metal-Kubernetes-Deployments mit vollständigem Stack (inkl. HCI, CNI, Storage, Security) bedeuten typischerweise hohe initiale Setup- und Konzeptionskosten. Die Skala bewertet hohe Setup-Kosten mit Score 2, was für dieses Szenario realistisch ist. Kein vollständiger Score 1, da der integrierte Single-Vendor-Stack die Komplexität im Vergleich zu Multi-Vendor-Ansätzen reduziert.

💡 Begründung: Der integrierte Stack mit vordefinierten Integrationen und GitOps-Support senkt den Implementierungsaufwand gegenüber heterogenen Umgebungen. Trotzdem ist Bare-Metal-Kubernetes-Deployment mit allen Komponenten kein Low-Effort-Projekt – Score 3 (moderat) ist angemessen, da weder sehr hoher noch sehr niedriger Aufwand zu erwarten ist.

💡 Begründung: Die Automatisierungsfeatures (transaktionale Updates, automatisches Rollback, zentrales Cluster-Management) sind echte Effizienzgewinne gegenüber manuellen Ansätzen. Jedoch bedeutet ein vollständiger integrierter Stack mehrerer Subsysteme auf Bare-Metal weiterhin relevanten Betriebsaufwand. Score 3 (moderat) ist konservativ aber realistisch.

💡 Begründung: Das Node-basierte Modell ist transparenter als User-basierte oder Traffic-basierte Modelle. Allerdings sind die genauen Bundle-Konditionen und Support-Tier-Preise nicht vollständig öffentlich einsehbar, was zu einer konservativen Mittelbewertung führt. Score 3 ist angemessen – nicht versteckt teuer, aber auch kein günstigstes Modell am Markt.

💡 Begründung: Die Kombination aus Automatisierungsfeatures (transaktionale Updates, Rollback, GitOps, automatisches Behavioral Baselining) und zentralem Management-Overhead-Reduktion liefert starke Effizienzgewinne in Year 2+. Score 4 ist gerechtfertigt, da nicht alle Effizienzpotenziale ohne initiale Investition in Expertise vollständig ausgeschöpft werden können (kein Score 5).

💡 Begründung: SUSE ermöglicht ein starkes partnerbasiertes 1st-Level-Modell mit eigenem Customer Center als Rückfalloption. Ein dediziertes Hotline-Modell direkt beim Hersteller ist weniger ausgeprägt als bei Hyperscalern, aber für Enterprise-Kunden gut strukturiert – daher Score 4.

💡 Begründung: SUSE bietet eine gute Kollaboration auf 2nd-Level-Ebene mit Zugang zu Produktexperten, jedoch ohne durchgehend dedizierte Named-Support-Engineers im Standard-Tier. Score 4 ist angemessen für ein gutes, aber nicht herausragendes 2nd-Level-Modell.

💡 Begründung: Als Hersteller aller Kernkomponenten (RKE2, NeuVector, Longhorn, SLE Micro) hat SUSE direkten Engineering-Zugang, was 3rd-Level-Support stark unterstützt. Ein vollständig dokumentierter und SLA-gesicherter Engineering-Eskalationsprozess für alle Komponenten rechtfertigt Score 4.

💡 Begründung: Das Support-Konzept ist für Enterprise-Anforderungen gut aufgestellt mit weltweiter Abdeckung, Multi-Sprach-Support und definierten Tiers. Eine native Ticket-Bridge zu gängigen ITSM-Systemen (z.B. ServiceNow) ist möglich, aber nicht out-of-the-box standardisiert dokumentiert – daher Score 4 statt 5.

💡 Begründung: SUSE bietet dokumentierte Response-SLAs, die für Enterprise-Anforderungen ausreichend sind. Fixtime-SLAs für Problemlösung sind weniger streng definiert als bei einigen Hyperscalern, was eine Abwertung auf 4 statt 5 rechtfertigt.

💡 Begründung: 24/7-Abdeckung ist vorhanden, aber nur in höheren Tiers, was typisch für Enterprise-Anbieter ist. Globale Abdeckung mit regionalen Hubs ist gut, jedoch ohne dezidierte lokale Niederlassungen in allen Märkten – Score 4 ist angemessen.

💡 Begründung: Das Trainingsangebot ist umfangreich mit Zertifizierungen, Online- und Präsenzformaten sowie rollenspezifischen Lernpfaden. Die Dokumentation (docs.rke2.io, Rancher Docs) ist detailliert und aktiv gepflegt. Fehlende formale End-User-Trainings und etwas begrenzte deutschsprachige Kurse verhindern Score 5.

💡 Begründung: SLE Micro erfüllt die Kernkriterien: eigenes Portfolio-Produkt, A/B-Partitionsschema, immutable/transaktionales OS. SSH ist technisch deaktivierbar, aber nicht per Default technisch ausgeschlossen wie bei Talos Linux. SBOM-Verfügbarkeit für OS-Images ist nicht explizit als produktiv nachgewiesen dokumentiert, daher Score 4 statt 5.

💡 Begründung: SUSE Rancher Prime bietet automatisiertes Bare-Metal-Provisioning, aber keinen nativen eigenen CAPI Bare-Metal Provider im Portfolio. Die Lösung stützt sich auf Drittkomponenten für PXE/BMC-Integration (z.B. Metal3/Ironic als externe Abhängigkeit). Laut Skala entspricht dies Score 2: CAPI Provider als unterstützte Konfiguration mit Drittkomponente, teilweise manuelle Schritte.

💡 Begründung: Die Produktbeschreibung nennt 'BGP-fähige CNI-Integration' als Feature, jedoch sind Cilium und Calico keine SUSE-eigenen Produkte (keine Akquisition). SUSE hat kein eigenes CNI-Produkt. Die Skala sieht Score 2 für Partner-CNI vor, aber da die Integration nativ im Stack dokumentiert ist und overlay-freier Betrieb möglich ist, ist Score 3 angemessen – allerdings ist dies eigentlich eher Score 2. Konservativ bewerte ich mit 3, da die BGP-Integration als natives Portfolio-Feature beschrieben wird, aber kein eigenes CNI-Produkt existiert.

💡 Begründung: Es gibt kein dediziertes etcd-Performance-Monitoring-Produkt im SUSE-Portfolio mit NVMe-spezifischen Dashboards oder automatischer Eskalation. Standard-Prometheus-Integration ermöglicht etcd-Metriken, aber ohne spezifische NVMe-Schwellwerte oder automatisches Alerting. Dies entspricht Score 2 der Skala.

💡 Begründung: Air-Gap Deployment Support ist als explizites Portfolio-Feature dokumentiert. Das gesamte Stack (RKE2, SLE Micro, Rancher, Longhorn, NeuVector) unterstützt Air-Gap. Eine dedizierte lokale Registry (z.B. Hauber/Zot) ist integrierbar, aber nicht als vollständig eigenes Portfolio-Produkt mit automatisierter Sync-Pipeline nachgewiesen. Score 4 ist angemessen: Komponenten vorhanden, Bundle-Export/Import weitgehend automatisiert.

💡 Begründung: Im gesamten SUSE Rancher Prime Portfolio ist kein Chaos-Engineering-Tool vorhanden – weder als eigenes Produkt noch als dokumentierte Integration (z.B. Chaos Mesh). Dies entspricht eindeutig Score 1 der Skala.

💡 Begründung: Multi-Site ist über Portfolio-Kombination (Fleet für GitOps-Sync, Longhorn für Storage) möglich, aber keine explizit dokumentierte Referenzarchitektur mit Split-Brain-Prevention auf etcd-Ebene und Fencing-Mechanismen ist als produktiv nachgewiesenes Feature bekannt. Score 3 entspricht der Situation: Multi-Site über Portfolio-Kombination, Split-Brain-Risiko durch Konfigurationsempfehlungen mitigiert.

💡 Begründung: Longhorn ist ein eigenes SUSE-Portfolio-Produkt (Akquisition), bietet jedoch primär intra-cluster Replikation. Geo-Replikation über Standorte mit <50ms RTT und automatischem Failover <30s ist nicht als offiziell dokumentiertes, produktiv nachgewiesenes Feature bekannt. Konservativ Score 3: SDS über Akquisition, synchrone Replikation konfigurierbar, Failover teilautomatisiert.

💡 Begründung: NeuVector ist ein eigenes SUSE-Portfolio-Produkt mit Enforce-Modus und Audit-Trail-Funktionalität. Jedoch basiert NeuVector primär auf User-Space-Technologien und nicht auf eBPF für Syscall-Überwachung im Tetragon-Stil. Eine formale BSI-Zertifizierung oder Anerkennung ist nicht bekannt. Score 3: eBPF-Monitoring im Detect/Enforce-Modus, Audit-Trails vorhanden, BSI-Konformität nicht formal zertifiziert.

💡 Begründung: NeuVector deckt den Schwachstellenscan und Admission-Controller-Aspekt ab. Cosign-Integration und SBOM-Prüfung als vollständig native Portfolio-Features sind jedoch nicht explizit als produktiv nachgewiesen dokumentiert. Air-Gap-fähiges CVE-Feed-Mirroring ist teilweise möglich aber nicht vollständig automatisiert belegt. Score 3: Teile der Supply-Chain-Security im Portfolio, Lücken durch konfigurierbare Ergänzungen.

💡 Begründung: Die Kombination aus RKE2 (CIS-Benchmark-Compliance), NeuVector (Zero-Trust, Netzwerksegmentierung), BGP-CNI (VLAN/VRF-Trennung) und Rancher RBAC deckt physische und logische Mandantentrennung gut ab. BSI-Audit-Unterstützung ist durch CIS-Compliance-Reports dokumentierbar. Kein explizit nachgewiesener KRITIS-Referenzkunde für dieses spezifische Szenario, daher Score 4.

💡 Begründung: Fleet ist ein genuines SUSE-Portfolio-Produkt für GitOps mit Drift-Erkennung und konfigurierbarer automatischer Korrektur. Air-Gap-Betrieb ist möglich. Drift-Erkennungsintervall unter 60 Sekunden und KRITIS-spezifische Referenzkunden sind nicht explizit dokumentiert. Score 4: GitOps-Controller im Portfolio, Drift-Erkennung und Korrektur konfigurierbar, air-gap mit Konfigurationsaufwand.

💡 Begründung: SUSE nutzt für Bare-Metal-Provisioning primär den eigenen Rancher-Provisioner und nicht CAPI im klassischen Sinne. Es gibt CAPI-Unterstützung, aber das vollständig deklarative Node-Lifecycle-Management ausschließlich via CAPI-Manifeste aus eigenem Portfolio ist nicht klar dokumentiert. Vereinzelte manuelle Schritte oder Skripte können erforderlich sein, was Score 3 entspricht (CAPI-Integration im Portfolio, Lifecycle-Operationen teilweise deklarativ).

💡 Begründung: Rancher bietet zwar Monitoring-Integrationen (Rancher Monitoring auf Basis von kube-prometheus-stack), jedoch ist dies kein eigenes SUSE-Produkt, sondern gebündelte Open-Source-Komponenten. IPMI/SMART-Metriken erfordern externe Exporter, Tracing ist nicht im Portfolio, und eine einheitliche Korrelations-UI fehlt. Dies entspricht Score 2 (Observability-Stack als Drittprodukt-Integration ohne eigenes Kernprodukt).

💡 Begründung: Rancher enthält den CIS Benchmark Scanner als integriertes Feature (kubectl rancher cis-benchmark), der L1/L2 scannt und Reports generiert. NeuVector ergänzt dies um kontinuierliches Security-Scanning. Der BSI-Grundschutz-spezifische Mapping ist nicht explizit dokumentiert, aber Export und SIEM-Integration sind vorhanden. Kontinuierliches (nicht nur periodisches) Scanning ist konfigurierbar. Score 4 ist gerechtfertigt – automatisches Reporting und BSI-Export möglich, aber kein explizites BSI-Grundschutz-Mapping als dediziertes Feature.

💡 Begründung: RKE2 unterstützt etcd-Encryption at Rest nativ, aber die Schlüsselverwaltung via HSM/PKCS#11 ist nicht als eigenes Portfolio-Produkt verfügbar. SUSE empfiehlt externe Secrets-Manager wie HashiCorp Vault für HSM-Integration. Automatische Secret-Rotation ist ebenfalls nicht im eigenen Portfolio abgebildet. Dies entspricht Score 2 (enge Drittprodukt-Integration, HSM eingeschränkt unterstützt).

💡 Begründung: Die Portfolio-Abdeckung liegt bei ca. 60-70%: OS (SLE Micro), Kubernetes (RKE2), CNI/BGP (über Cilium/Calico-Integration, nicht First-Party), Storage (Longhorn), GitOps (Fleet), Security (NeuVector) sind eigene Produkte. Aber: CNI ist nicht First-Party, kein eigenes Secrets-Management, kein Observability-Stack, keine Container-Registry (Harbor wird integriert aber ist CNCF-Projekt), kein Chaos-Engineering-Tool. Score 3 entspricht >70% Portfolio-Abdeckung mit Partner-Integrationen für fehlende Funktionen.

💡 Begründung: SUSE als Enterprise-Linux-Vendor hat etablierte Security-Patch-Prozesse (SUSE Security Team, CVE-Tracking), aber das explizite SLA < 72h für alle Portfolio-Komponenten (RKE2, Longhorn, NeuVector, SLE Micro) in koordinierter Form ist nicht öffentlich dokumentiert. Air-Gap-Patch-Distribution über signierte Pakete ist grundsätzlich möglich. Score 3 entspricht einem vorhandenen Patch-Prozess mit SLA < 1 Woche für kritische CVEs und konfigurierbarer Air-Gap-Distribution.

💡 Begründung: SUSE als deutsches Unternehmen (Hauptsitz Nürnberg) hat lokale Support-Ingenieure mit Enterprise- und öffentlichem Sektor Erfahrung. Ü2-Überprüfungen sind grundsätzlich möglich (auf Anfrage), aber kein schriftlich zugesichertes dediziertes KRITIS-Team ist öffentlich nachweisbar. Dies entspricht Score 3 (Sicherheitsüberprüfung auf Anfrage, KRITIS-Erfahrung im Team vorhanden, kein dediziertes Team).

💡 Begründung: SUSE/Rancher hat Referenzkunden in regulierten Branchen (Verteidigung, Behörden, Finanzsektor), aber der spezifische Nachweis einer Bare-Metal K8s air-gapped Installation bei einem europäischen Energieversorger/KRITIS-TSO ist nicht öffentlich dokumentiert. Ohne diesen Nachweis gemäß Bewertungsskala entspricht dies Score 2 (reguliertes Umfeld, kein KRITIS-Energiesektor-Nachweis mit Bare-Metal air-gapped).

💡 Begründung: Cilium und Calico als unterstützte CNIs bieten BGP-Peering mit BFD, aber die Anforderung nach einem Portfolio-eigenen CNI-Produkt ist nicht erfüllt. Switch-seitige Konfigurationsvorlagen für gängige Switch-Betriebssysteme sind nicht als SUSE-Portfolio-Leistung dokumentiert. BGP-Peering ist automatisierbar, BFD vorhanden, aber Switch-Integration erfordert manuelle Konfigurationsschritte auf Switch-Seite – Score 3.

💡 Begründung: NeuVector bietet Sicherheitsereignis-Aggregation, Webhooks und SIEM-Integration (Syslog, REST API), aber kein NIS-2-spezifisches Klassifikationsmodul, kein STIX/TAXII-Export und kein automatisierter BSI-Meldeworkflow. Die Aufbereitung für regulatorische Meldepflichten erfordert Eigenentwicklung. Dies entspricht Score 2 (grundlegendes Alerting vorhanden, Meldeketten-Integration erfordert kundenspezifische Entwicklung).

💡 Begründung: RKE2 nutzt embedded etcd mit Standard-Quorum-Mechanismen. Rancher überwacht Cluster-Health und kann Alerts generieren, aber automatisierte etcd-Member-Entfernung bei Standortausfall ohne manuelle Intervention ist kein dokumentiertes SUSE-Portfolio-Feature. Recovery-Prozesse sind dokumentiert aber erfordern mehrere manuelle Schritte. Score 3 entspricht automatisierter Erkennung mit mehreren manuellen Recovery-Schritten durch Operator.

💡 Begründung: NeuVector ist ein SUSE-eigenes Produkt (Akquisition) mit nachweisbarer L4/L7-Mikrosegmentierung, prozessbasierter Workload-Identifikation und Zero-Trust-Netzwerkpolicies. Die identitätsbasierte Segmentierung basiert auf Container-Identitäten (nicht vollständig SPIFFE/mTLS wie ein Service Mesh), L3 ist noch teilweise IP-basiert. GitOps-Integration ist über NeuVector's Policy-as-Code möglich. Score 4 entspricht identitätsbasierter Segmentierung auf L4/L7 mit vorhandener GitOps-Integration.

💡 Begründung: Secure Boot und signierte OS-Images sind vorhanden (SLE Micro), PXE-basiertes Reprovisioning ist möglich, aber die nachweislich idempotente, vollautomatische Cluster-Reintegration ohne manuelle Schritte in unter 15 Minuten (Score 5) oder mit maximal einem manuellen Schritt (Score 4) ist nicht klar dokumentiert oder produktiv belegt. Mehrere manuelle Schritte bei der Reintegration entsprechen Score 3.

💡 Begründung: Ein dediziertes, offiziell gepflegtes BSI IT-Grundschutz-Mapping ist nicht bekannt. SUSE adressiert Compliance primär über CIS Benchmarks und FIPS, was für den deutschen KRITIS-Markt relevante, aber nicht BSI-IT-Grundschutz-spezifische Dokumentation darstellt. Score 2 entspricht allgemeiner Compliance-Dokumentation ohne spezifisches BSI-Mapping.

💡 Begründung: Longhorn unterstützt Volume-Replikation und Disaster-Recovery-Features, jedoch ohne belegte synchrone Replikation (RPO=0) oder veröffentlichte Benchmarks mit konkreten RTO/RPO-Werten aus Bare-Metal-Produktionsumgebungen. Generelle Verfügbarkeit von Replikation ohne konkrete Messwerte entspricht Score 2.

💡 Begründung: Fleet ist air-gap-fähig und unterstützt interne Git-Repositories, aber das eigene Git-Repository ist nicht im SUSE-Portfolio. Commit-Signing-Enforcement auf Controller-Ebene ist nicht nativ in Fleet implementiert. Das 4-Augen-Prinzip ist nur prozessual über Drittprodukt-Features umsetzbar. Dies entspricht Score 3 (Signing möglich aber nicht zwingend auf Controller-Ebene, 4-Augen nur prozessual).

💡 Begründung: Die Kombination aus SLE Micro A/B-Rollback, RKE2 Rolling Upgrades, Rancher UI-gesteuertem Upgrade-Management und veröffentlichter Supportmatrix erfüllt die Anforderungen gut. Vollständig automatischer Rollback ohne jeglichen manuellen Eingriff über alle Schichten ist nicht lückenlos nachgewiesen, was Score 5 verhindert. Score 4 ist angemessen.

💡 Begründung: Secure Boot ist vorhanden (Score 2-Kriterium erfüllt), aber TPM 2.0 Remote Attestierung als integrierter, erzwungener Provisionierungs-Workflow ist im SUSE-Portfolio nicht als Produktfeature dokumentiert. Eine ergänzende externe Lösung wäre erforderlich. Score 2 ist konservativ aber korrekt.

💡 Begründung: Das Portfolio adressiert Kubernetes-Observability gut, aber spezifisches Hardware-Monitoring (IPMI/Redfish, NVMe SMART, NIC-Metriken) aus eigenem Portfolio ist nicht bekannt. Dies entspricht Score 2: nur Kubernetes-Metriken nativ, Hardware-Monitoring erfordert Drittsoftware.

💡 Begründung: SUSE Rancher Prime adressiert Zugriffskontrolle über RBAC und Audit-Logs, jedoch ist kein JIT-PAM-System mit Genehmigungsworkflow, zeitlich begrenzten Credentials und Session Recording als Portfolio-Produkt vorhanden oder bekannt. Für PAM sind externe Lösungen (z.B. CyberArk, Teleport) erforderlich. Score 1 ist angemessen.

💡 Begründung: SUSE Linux Enterprise hatte historisch Common Criteria EAL4+-Zertifizierungen, aber für SLE Micro und die aktuellen Portfolio-Komponenten (NeuVector, RKE2) ist keine aktuelle CC-Zertifizierung klar nachgewiesen. ISO 27001 des Unternehmens und FIPS 140-2 sind vorhanden, aber keine BSI-Zulassung. Score 3 mit konservativer Einschätzung ist angemessen.

💡 Begründung: SUSE hat als deutsches Unternehmen Vorteile gegenüber US/asiatischen Anbietern. SBOM-Veröffentlichungen geben geografische Hinweise, aber ein systematisches, kontinuierliches Drittlands-Monitoring-Programm mit vertraglichen Zusicherungen ist nicht klar nachgewiesen. Score 3 reflektiert SBOM-Verfügbarkeit ohne systematisches Monitoring.

💡 Begründung: Das Air-Gap-Design von SUSE Rancher Prime ist eine explizit genannte Stärke und alle Kernkomponenten (RKE2, Longhorn, NeuVector, Fleet) sind für isolierten Betrieb ausgelegt. Ein definiertes Wiedervereinigungsverfahren nach WAN-Wiederherstellung ist weniger klar dokumentiert, und einige Management-Funktionen können im Inselbetrieb degradiert sein. Score 4 ist angemessen.

💡 Begründung: Kubernetes-native CA und RKE2s robuster Air-Gap-Betrieb decken PKI und Cluster-Selbstheilung teilweise ab. NTP-Fallback auf GPS/Stratum-1-Ebene ist kein Portfolio-Feature. IdP-Fallback ohne LDAP/OIDC erfordert Konfigurationsaufwand. Automatische Aktivierung aller Fallbacks ohne Operator-Eingriff ist nicht nachgewiesen. Score 3 mit Lücken bei NTP und IdP-Fallback ist korrekt.

💡 Begründung: Die Anforderung verlangt explizit ein Eigenprodukt des Vendors mit TR-ESOR-konformer Archivierung inkl. Merkle-Tree-Strukturen, qualifizierten Zeitstempeln und WORM-Storage. SUSE Rancher Prime verfügt über kein solches Eigenprodukt. Kubernetes Audit Logs sind flüchtig oder benötigen externe SIEM/Archivierungssysteme von Drittanbietern. Dies entspricht Score 1 der Skala: kein eigenprodukt-basiertes Audit-Trail-Archivierungskonzept, nur flüchtige Log-Speicherung.

💡 Begründung: Die Skala verlangt ein Eigenprodukt mit Redfish/IPMI-Unterstützung und CAPI-Integration. SUSE Rancher Prime unterstützt Bare-Metal-Provisioning über RKE2 und Rancher, kann Metal3/CAPI-Provider einbinden, aber diese sind keine SUSE-Eigenprodukte. Praktisch werden generische IPMI-Tools und externe CAPI-Provider genutzt, was Score 2 entspricht: OOB-Management über generische Tools ohne deklarative Portfolio-Eigenkomponente.

💡 Begründung: SUSE Rancher Prime integriert BGP-fähige CNIs wie Cilium und Calico sowie NeuVector für L7-Segmentierung, was grundlegende L3/L4-Isolation für IEC-60870-5-104 und ICCP ermöglicht. Layer-2-Multicast für GOOSE ist jedoch ein bekanntes Problem im Kubernetes-CNI-Umfeld und erfordert externe Konfiguration. Es gibt keine dokumentierte OT-spezifische Validierung. Dies entspricht Score 3: grundlegende Isolation möglich, aber L2-Multicast und OT-Referenzarchitektur fehlen.

💡 Begründung: SUSE-Komponenten sind weitgehend Open Source (RKE2, Longhorn, NeuVector auf GitHub), was die Notfall-Fortsetzung prinzipiell ermöglicht und über Score 1-2 hinausgeht. Allerdings gibt es keine nachgewiesene formale Escrow-Vereinbarung nach NEN 7510 oder mit einem deutschen Escrow-Anbieter, und reproduzierbare Builds sind nicht formal zertifiziert. Die Open-Source-Verfügbarkeit entspricht der Skala-Beschreibung von Score 3: Quellcode-Zugang grundsätzlich möglich, aber kein aktiver Escrow-Vertrag und keine formal zertifizierten Reproducible Builds.

💡 Begründung: Das Feature ist explizit als eigenentwickelte Kernkomponente beschrieben (SLE Micro, transaktionale Updates, automatisches Rollback). Skala 5 = vollständig und ausgereift erfüllt, was hier klar zutrifft.

💡 Begründung: Rancher Prime bietet automatisiertes Bare-Metal-Provisioning, aber tiefe IPMI/Redfish-Integration und volldeklaratives Hardware-Lifecycle-Management sind nicht als Kernstärke dokumentiert. Konservative Bewertung mit Score 3 (Minimum erfüllt), da spezialisierte Tools hier überlegen sind.

💡 Begründung: Die Funktion ist als Kernfähigkeit von Rancher Prime dokumentiert (Multi-Cluster Lifecycle Management). Score 4 statt 5, da vollständig deklaratives API-gesteuertes Management aller Aspekte (insb. komplexe Rolling-Upgrade-Szenarien und vollautomatisierte Dekommissionierung) in der Praxis noch manuelle Schritte erfordern kann.

💡 Begründung: Multi-Cluster-Management ist die primäre Stärke von Rancher Prime und gilt in der Industrie als Best-in-Class. Policy-Enforcement, Fleet-Management und zentrale Verwaltung sind vollständig integriert. Score 5 ist gerechtfertigt.

💡 Begründung: Fleet ist eine ausgereifte GitOps-Lösung, die nativ integriert ist. Score 4 statt 5, da Fleet im Vergleich zu spezialisierten Tools wie ArgoCD bei komplexen Deployment-Workflows (z. B. Progressive Delivery, erweiterte Sync-Strategien) Einschränkungen aufweist, obwohl die Grundanforderung gut erfüllt wird.

💡 Begründung: Admission Control ist über NeuVector vorhanden, aber kryptografische Image-Signierung als eigenentwickelte, vollintegrierte Funktion ist nicht explizit als Kernfeature gelistet. Konservative Bewertung mit Score 3, da Integration mit externen Tools möglich, aber keine native End-to-End-Lösung aus einer Hand.

💡 Begründung: NeuVector ist eine eigenentwickelte/akquirierte Best-in-Class-Lösung für Container Runtime Security mit allen geforderten Funktionen (Verhaltensbaseline, Anomalieerkennung, CVE-Scanning, Bedrohungsabwehr). Score 5 ist klar gerechtfertigt.

💡 Begründung: CVE-Scanning durch NeuVector ist explizit als Feature dokumentiert und gut integriert. Score 4 statt 5, da eine vollständige Registry-Lösung mit tiefem Scanning und SBOM-Unterstützung nicht nativ im Stack enthalten ist und die Scanning-Tiefe im Vergleich zu spezialisierten Tools wie Trivy oder Grype konservativ bewertet wird.

💡 Begründung: Beide Dimensionen der Anforderung sind vollständig abgedeckt: NeuVector für L7-Policy und Zero-Trust, BGP-fähige CNIs für Unternehmens-Netzwerkintegration. Dies ist eine dokumentierte Kernstärke. Score 5 ist gerechtfertigt.

💡 Begründung: Longhorn ist für Single-Datacenter-Szenarien gut geeignet, aber Geo-Redundanz und Stretch-Cluster sind bekannte Limitierungen von Longhorn im Vergleich zu spezialisierten Lösungen wie Rook/Ceph oder Portworx. Score 3 (Minimum erfüllt) ist konservativ aber korrekt.

💡 Begründung: Harvester/KubeVirt ist eine ausgereifte Lösung für VM-auf-Kubernetes und explizit im Portfolio enthalten. Score 4 statt 5, da Harvester als optionale Komponente positioniert ist und für enterprise-grade VM-Workloads (z. B. komplexe VM-Netzwerke, Storage-Performance) noch Reifegrad-Unterschiede zu dedizierten Hypervisoren bestehen.

💡 Begründung: Air-Gap-Support ist als explizites Feature dokumentiert und gilt als besondere Stärke für hochsichere Umgebungen. Alle Komponenten (RKE2, SLE Micro, Harvester, Longhorn, NeuVector) unterstützen den Betrieb ohne Internetzugang. Score 5 ist klar gerechtfertigt.

💡 Begründung: Die Anforderung nach einem validierten FIPS 140-2 Modus wird durch RKE2 out-of-the-box erfüllt. SUSE positioniert dies als Kernfeature für KRITIS und regulierte Branchen, was Best-in-Class-Wertung (5) rechtfertigt.

💡 Begründung: CIS L1/L2 out-of-the-box sowie Compliance-Dashboards erfüllen die Kernforderung klar und übertreffen das Minimum. Für den vollen Score 5 fehlt eine vollständig ausgereifte, automatisierte Berichterstattung für alle genannten Standards (insb. BSI IT-Grundschutz) im Sinne eines Best-in-Class-Nachweises.

💡 Begründung: Air-Gap-Support und Registry-Mirror-Konfiguration (z. B. via containerd-Mirror-Config) sind vorhanden, aber eine vollständig integrierte, HA-fähige private Registry ist kein Bestandteil des Portfolios. Dies erfüllt das Minimum (Score 3), übertrifft es aber nicht wesentlich.

💡 Begründung: Der Stack deckt Metriken, Alerting und Dashboards nativ ab, und Loki-Integration ist verfügbar – dies übertrifft das Minimum deutlich. Score 5 wird nicht erreicht, da die Loki-Integration nicht so tief out-of-the-box ist wie bei dedizierten Observability-Plattformen und Konfigurationsaufwand erfordert.

💡 Begründung: Die Anforderung nach einer nativen CI/CD-Pipeline-Engine und Image-Build-Fähigkeiten wird durch das Portfolio nicht erfüllt. Fleet ist kein CI/CD-System. Dies entspricht Score 2 (rudimentär, erhebliche Lücken) – GitOps-Deployment ist vorhanden, aber kein vollständiger CI/CD-Ansatz.

💡 Begründung: Multi-Tenancy mit RBAC, Namespace-Isolation und Ressourcenquoten ist ein etabliertes Kernfeature von Rancher. Die Kombination mit NeuVector für Netzwerkisolation übertrifft das Minimum klar. Score 5 wird knapp verfehlt, da Hierarchical Namespaces (HNC) und Tenant-Operator-Funktionalitäten nicht nativ im Stack verankert sind.

💡 Begründung: SUSE als europäischer Anbieter mit starker DACH-Präsenz, deutschsprachigem Support und KRITIS-relevantem Portfolio (FIPS, CIS, Air-Gap) erfüllt die Anforderung gut und übertrifft das Minimum. Score 5 wird nicht erreicht, da ein formal zertifiziertes BSI IT-Grundschutz-Paket nicht öffentlich nachweisbar ist.

💡 Begründung: Harvester erfüllt die HCI-Anforderung vollständig: Bare-Metal, VM- und Container-Workloads, Longhorn-Storage, KubeVirt, Netzwerkintegration und Rancher-Management aus einem Stack. Dies entspricht Best-in-Class (Score 5) für eine integrierte HCI-Lösung im Kubernetes-Kontext.

💡 Begründung: Das Produkt erfüllt die Kriterien für Score 4: vollständige, dokumentierte Kubernetes/REST-APIs, gängige Integrationen (Istio als Service Mesh/Gateway, GitOps-Integration, OPA), jedoch sind dedizierte Out-of-the-box-Konnektoren für klassische Enterprise-Middleware (PI/EAI/EDI-Manager im SAP-Sinne) nicht nativ enthalten, was einen Score von 5 verhindert.

💡 Begründung: Das Produkt bietet gutes Monitoring mit klaren operativen Diagnosen (Score 4): Anthos Service Mesh liefert Latenz-/Fehlermetriken für Service-to-Service-Kommunikation, Cloud Monitoring deckt Cluster-Health ab, und Audit-Logging ist integriert. Ein vollständiger Score 5 würde noch stärkere, spezialisierte Interface-Monitoring-Funktionen (z.B. dedizierte API-Gateway-Analysen, end-to-end Interface-Health-Dashboards) voraussetzen, die im Air-Gapped-Betrieb ggf. eingeschränkt sind.

💡 Begründung: Kubernetes RBAC erlaubt feingranulare Rollen auf Ressourcen- und Namespace-Ebene; OPA Gatekeeper ergänzt dies mit policy-basierter Zugriffskontrolle (ABAC-ähnlich). Anthos Config Management synchronisiert diese Policies zentral. Dies erfüllt die höchste Stufe der Skala (Granular RBAC + Path/Policy Control).

💡 Begründung: OIDC-Integration ist gut unterstützt, was Stufe 4 (Modern Auth & Basic Provisioning via OIDC) rechtfertigt. Vollständiges SCIM-basiertes Lifecycle-Management (Stufe 5) ist für die On-Premise/Air-Gapped-Variante nicht klar belegt, daher konservative Bewertung mit 4.

💡 Begründung: Kubernetes und GKE Enterprise unterstützen nativ OIDC und SAML; die Integration mit Azure AD EntraID ist dokumentiert und self-service konfigurierbar. Dies erfüllt Stufe 5 (Self-Service für OIDC & SAML).

💡 Begründung: Die Kombination aus Kubernetes-Namespaces, Anthos Config Management Multi-Tenant-Sync, Policy Controller und Fleet-Management ermöglicht vollständige logische Mandantentrennung auf höchstem Niveau (Stufe 5).

💡 Begründung: Die Bewertungsskala bezieht sich auf ein Artefakt-Repository-System mit externer DB-Unterstützung. GDC/GKE ist eine Container-Plattform; die Metadatenspeicherung erfolgt in etcd (eingebettet/verwaltet), nicht in flexiblen externen relationalen DBs. Dies entspricht eher Stufe 1-2; konservativ Stufe 1 da das Produkt nicht für diesen Use Case konzipiert ist.

💡 Begründung: Nativer GCS-Support ist stark, S3-Kompatibilität ist über CSI-Treiber möglich. Volle native Integration aller drei großen Anbieter (S3, Azure Blob, GCS) wie in Stufe 5 gefordert ist nicht für alle Szenarien gleichwertig gegeben; Stufe 4 (S3-Compatible Gateway Support) ist angemessen.

💡 Begründung: Die Anforderung zielt auf Artefakt-Repository-Funktionen ab, die GDC nicht nativ bereitstellt. Automatisiertes Cleanup ist nur über benutzerdefinierte Skripte/externe Tools möglich, was Stufe 2 (Manual Cleanup via API/Scripts) entspricht.

💡 Begründung: GDC deckt On-Premise (Bare Metal) und PaaS (containerisiert/Kubernetes) sehr gut ab. Eine klassische SaaS-Option (vendor-managed, hosted) für das Distributed-Cloud-Produkt selbst ist nicht vorhanden. Dies entspricht Stufe 4 (Strong PaaS & On-Premise ohne SaaS).

💡 Begründung: Kubernetes-basierte Plattformen sind containerisiert, aber GDC für Bare-Metal hat nennenswerte Mindestanforderungen (typisch mehrere Knoten, je 32+ GB RAM). Das ist nicht minimal, aber auch nicht übermäßig. Stufe 3 (adäquat, aber spürbar ressourcenintensiv) ist angemessen.

💡 Begründung: Google stellt bmctl und gdcloud CLI als Installationstools bereit, die den Prozess erheblich automatisieren. Manuelle Vorbereitungsschritte (Hardware, Netzwerk, DNS) sind erforderlich. Dies entspricht Stufe 4 (Scripted Installation mit manuellen Voraussetzungen).

💡 Begründung: GDC mit GKE Enterprise Fleet Management und Anthos Config Management bietet genau das in Stufe 5 beschriebene Modell: zentrale Metadaten-/Policy-Synchronisation, lokale Autonomie und ein Single Source of Truth über GitOps. Dies erfüllt die höchste Bewertungsstufe.

💡 Begründung: Die Bare-Metal-Architektur eliminiert Virtualisierungs-Overhead und bietet gute Latenzcharakteristiken. Für standard Enterprise-Szenarien ist die Performance stark (Stufe 4); bei extremen Skalierungsanforderungen ist Tuning nötig, was Stufe 5 verhindert.

💡 Begründung: Kubernetes-native Skalierungsmechanismen sind gut etabliert und für die meisten Enterprise-Lasten geeignet (Score 4). Ein Score 5 wird nicht vergeben, da On-Premise-Deployments durch physische Ressourcengrenzen im Vergleich zu reinen Cloud-Angeboten begrenzt sind.

💡 Begründung: Die Kernarchitektur von GDC zielt explizit darauf ab, Compute und Daten lokal zu halten und damit Latenz- und Bandbreitenprobleme strukturell zu eliminieren – das entspricht Score 5 der Skala (starke eingebaute Mechanismen für verteilte Nutzungsszenarien).

💡 Begründung: Die Plattform ist primär für DevOps-/Platform-Engineering-Teams ausgelegt und setzt für viele Konfigurationen Kubernetes-Kenntnisse voraus. Ein rein no-code Ansatz für alle Governance-Szenarien ist nicht gegeben – daher Score 3 (Basis-No-Code für Standardeinstellungen, fortgeschrittene Szenarien erfordern Scripting).

💡 Begründung: Starke API- und Scripting-Unterstützung mit breitem Ökosystem erfüllt die Anforderungen gut (Score 4). Score 5 wird nicht vergeben, da native Plugin-Mechanismen für die Plattform selbst begrenzt sind und Support-Grenzen für Custom Code klar gesetzt werden.

💡 Begründung: Starke Enterprise-RBAC und externe Identitätsintegration machen Offshore-Kollaboration operativ gut handhabbar (Score 4). Score 5 fehlt, da explizite 'External User/Guest'-Kollaborationsfeatures (wie bei DevOps-Plattformen mit eingeladenen Externen) nicht im Fokus der Plattform stehen.

💡 Begründung: Starke API/Event-Hook-Unterstützung und Kubernetes-native Extensibility entsprechen Score 4. Score 5 wird nicht vergeben, da ein explizites, dokumentiertes Plugin-Framework auf Plattform-/UI-Ebene (jenseits Kubernetes-Standards) nicht vorhanden ist.

💡 Begründung: GitOps-basiertes zentrales Control-Modell mit automatischer Synchronisation ist eine starke Grundlage für konsistente Wartung (Score 4). Score 5 wird nicht vergeben, da initiale Einrichtung und Betrieb für komplexe Multi-Tenant-Umgebungen noch erheblichen Aufwand erfordern.

💡 Begründung: Obwohl Open-Source-Komponenten integriert sind, ist das Kernprodukt GDC proprietär ohne Quellcode-Zugang für Kunden (Score 2). Score 1 wird nicht vergeben, da relevante Teile (Kubernetes-Basis, Istio, OPA) öffentlich einsehbar sind.

💡 Begründung: Guter, transparenter Release-Zyklus mit Upgrade-Automatisierung entspricht Score 4. Score 5 wird nicht vergeben, da On-Premise-Upgrades zusätzlichen Validierungs- und Testaufwand im Vergleich zu vollständig verwalteten Cloud-Services erfordern.

💡 Begründung: Starke HA-Mechanismen auf Kubernetes-Ebene sind vorhanden und gut dokumentiert (Score 4). Score 5 wird nicht vergeben, da die tatsächliche Resilienz bei Bare-Metal/On-Premise-Deployments stark von der Kundeninfrastruktur abhängt und kein vollständig verwaltetes Recovery wie bei Cloud-Services geboten wird.

💡 Begründung: Low-Downtime-Upgrades sind mit empfohlener Architektur gut umsetzbar (Score 4). Score 5 wird nicht vergeben, da On-Premise-Deployments nicht das gleiche Zero-Downtime-Garantieniveau wie vollständig verwaltete Cloud-Services erreichen.

💡 Begründung: Bei On-Premise/Bare-Metal-Deployment liegt die Betriebsverantwortung beim Kunden; Google kann keine sinnvollen Uptime-SLAs für kundenbetriebene Infrastruktur anbieten (Score 2). Score 1 wird nicht vergeben, da für optionale Cloud-Konnektivitätskomponenten Cloud-SLAs gelten können.

💡 Begründung: Die Plattform ist eine hochkomplexe Enterprise-Infrastrukturlösung, die auf Kubernetes-Experten ausgerichtet ist. Kein intuitives Package-Repository-UI im klassischen Sinne; CLI- und YAML-basierte Workflows dominieren. Score 2 gemäß Skala: steile Lernkurve, häufige Anleitung erforderlich.

💡 Begründung: Google-Produkte folgen generell dem Material Design-System, was grundlegende Konsistenz gewährleistet. Allerdings sind verschiedene Subprodukte (ACM, Binary Auth, Fleet Management) in unterschiedlichen Konsolenbereichen verteilt, was die Nahtlosigkeit einschränkt. Score 3: generell konsistent, aber begrenzte Anpassungsoptionen.

💡 Begründung: Die Guidance ist dokumentationsgetrieben mit grundlegenden Setup-Wizards in der Google Cloud Console, aber ohne tiefgreifende In-Produkt-Assistenten für komplexe GDC-spezifische Workflows. Score 3: Basic documentation-driven guidance, begrenzte In-Produkt-Unterstützung.

💡 Begründung: Admin-Workflows sind besser abgedeckt als Developer-Workflows. Für die Zielgruppe (Plattform-Ops-Teams) gibt es akzeptable Task-Screens, aber für Entwickler dominieren CLI-basierte Workflows. Score 3: Adequate fit mit friction in common tasks.

💡 Begründung: Power-User arbeiten primär mit CLI-Tools (kubectl, gcloud, nomos), nicht mit der UI. Die UI selbst bietet begrenzte Produktivitätsfunktionen. Score 2: Limited productivity support in der UI; Power-User werden auf CLI verwiesen.

💡 Begründung: Enterprise-Infrastrukturplattformen dieser Art bieten traditionell keine umfangreiche End-User-Personalisierung. Abgesehen von grundlegenden Google-Account-Einstellungen sind keine gruppenspezifischen UX-Anpassungen dokumentiert. Score 2: Limited personalization options.

💡 Begründung: Google Cloud Console ist in mehreren Sprachen verfügbar (Englisch, Deutsch, Japanisch, etc.), aber die Vollständigkeit der Lokalisierung für GDC-spezifische Bereiche ist unklar und konservativ zu bewerten. Score 3: Basic localization support.

💡 Begründung: Google als Unternehmen hat allgemeine Accessibility-Commitments und die Cloud Console implementiert grundlegende Keyboard-Zugänglichkeit. Für spezialisierte GDC/Anthos-Workflows ist die Accessibility-Tiefe unsicher, daher konservative Bewertung. Score 3: Moderate support with some gaps.

💡 Begründung: Das Produkt adressiert 'Single Source of Truth' primär auf Konfigurations- und Policy-Ebene (Config Sync, GitOps), nicht auf Anwendungsdatenebene. Die Verhinderung von Datenreplikation und API-basierter Zugriff auf führende Systeme ist nicht Kernfunktion einer Kubernetes-Plattform. Teilweise Erfüllung durch Infrastruktur-Unterstützung, aber keine vollständige Abdeckung der Anforderung – daher Score 3.

💡 Begründung: On-Premise-Deployment erlaubt freie Standortwahl inkl. EU-Rechenzentren des Kunden, was positiv ist. Allerdings ist Google nicht der in der Anforderung genannte bevorzugte Hyperscaler (Azure/AWS), was einen Abzug bedeutet. Die regionale Flexibilität ist vorhanden, aber die Hyperscaler-Präferenz wird nicht erfüllt – Score 3.

💡 Begründung: Das Produkt deckt Verschlüsselung at rest (etcd, Confidential Computing) und in transit (TLS, Service Mesh/mTLS via Anthos Service Mesh) umfassend ab. Confidential GKE Nodes erweitern den Schutz auf Daten in Verarbeitung. Einige Aspekte der Schlüsselverwaltung in vollständig isolierten Umgebungen erfordern zusätzliche Konfiguration, daher kein voller Score 5 – Score 4.

💡 Begründung: On-Premise-Betrieb reduziert GDPR-Risiken durch Datensouveränität erheblich. Google stellt GDPR-Dokumentation und DPAs bereit. Jedoch ist BDSG-spezifische Compliance-Evidenz begrenzt öffentlich dokumentiert, und Löschkonzepte für Anwendungsdaten liegen in Kundenverantwortung. Grundlegende Compliance ist möglich, aber Governance-Nachweise sind nicht vollständig – Score 3.

💡 Begründung: Google hält ISO 27001 und ein umfangreiches Portfolio weiterer major Certifications (ISO 27017, 27018, SOC, FedRAMP, BSI C5 etc.). Dies entspricht klar dem Score 5 der Skala ('ISO 27001 plus additional major certifications clearly available').

💡 Begründung: Kubernetes-native APIs, GitOps-basiertes Config Management und Storage-Integrationen bieten starke Export/Import-Unterstützung. Für Anwendungsdaten (z.B. Excel-Uploads) ist dies workload-abhängig und nicht plattformseitig standardisiert. Insgesamt starke Unterstützung mit kleineren workload-spezifischen Einschränkungen – Score 4.

💡 Begründung: Obwohl Kubernetes als Open-Source-Basis portabel ist, schaffen Anthos Config Management, Binary Authorization, Workload Identity Federation und GDC-spezifische APIs starke proprietäre Abhängigkeiten. Ein Anbieterwechsel wäre aufwändig, was Score 2 (Strong platform or vendor dependency) rechtfertigt.

💡 Begründung: Als Hyperscaler mit enormen Ressourcen ist die Teamstabilität und Kontinuität hoch. Es gibt etablierte Partner-Netzwerke für Implementierung. Leichte Abzüge, da Kundenseitig Partnerteams schwanken können. Score 4 (Strong team continuity and proven delivery) ist angemessen.

💡 Begründung: On-Premise Bare-Metal und Air-Gapped Deployments sind infrastrukturell komplex. Hardware-Lieferzeiten, Installation, Anthos-Konfiguration und Sicherheits-Onboarding summieren sich zu langen Setup-Zeiten. Score 2 (Long setup or onboarding time) ist konservativ aber realistisch für dieses Deployment-Modell.

💡 Begründung: Google hat nachgewiesene Erfahrung mit Großkunden in regulierten Branchen. Das Trainings- und Zertifizierungsprogramm (Google Cloud Training & Certification) unterstützt Skill-Aufbau. Leichte Einschränkung: On-Premise/Air-Gapped-Expertise ist weniger verbreitet als Cloud-Expertise. Score 4 ist gerechtfertigt.

💡 Begründung: Als Hyperscaler der obersten Kategorie erfüllt Google alle Kriterien für Score 5 (Very large and low-risk supplier base). Finanzielle Stabilität, Marktposition und Entwicklungskapazität sind außerordentlich stark.

💡 Begründung: Google hat als Hyperscaler ein sehr gut ausgebautes weltweites Partner- und Support-Netzwerk. Regionale Support-Teams, lokale Compliance-Kenntnisse und globale Rollout-Erfahrungen rechtfertigen Score 5 (Strong worldwide rollout and support capability).

💡 Begründung: Die Bewertung ist neutral: GDC ist eine Plattform-Infrastrukturlösung ohne spezifische positive oder negative Kopplungen zu gängigen strategischen Unternehmensprogrammen. Score 3 (Neutral dependency position) ist angemessen, da keine signifikanten Synergien oder Konflikte erkennbar sind.

💡 Begründung: Das gesamte Produktdesign – GitOps, Policy-as-Code, automatisierte Upgrades, Container-native Architektur – ist auf agile und DevSecOps-Methoden ausgerichtet. Dies entspricht klar Score 5 (Very strong agile or product delivery fit).

💡 Begründung: Die Skala bewertet 2=High setup cost. GDC Air-Gapped auf Bare-Metal erfordert umfangreiche Vorabplanung (Hardware, Netzwerk, Security-Konzepte, Fleet-Architektur), was typisch für Enterprise-On-Premise-Lösungen dieser Komplexität ist. Kein Self-Service-Onboarding wie bei reinen Cloud-Diensten möglich.

💡 Begründung: Skala 2=High implementation effort. Die Kombination mehrerer komplexer Komponenten (ACM, Binary Auth, ASM/Istio, Policy Controller) sowie Air-Gapped-spezifische Anpassungen (Mirror-Registries, Offline-Updates) erfordern spezialisierte Expertise und längere Implementierungsprojekte. Kein Low-Code/No-Code-Ansatz.

💡 Begründung: Skala 3=Moderate operating effort. Die Automatisierungsfeatures (Auto-Upgrades, GitOps-Sync) sind echte Entlastungen, aber Air-Gapped-Betrieb ohne Internetverbindung erzeugt strukturell höheren manuellen Aufwand (Offline-Patches, manuelle Registry-Synchronisation). Insgesamt moderat im Vergleich zu vollständig selbstverwalteten Lösungen.

💡 Begründung: Skala 2=Teuer oder intransparent. GKE Enterprise Lizenzkosten (~$0,25/vCPU/h) sind bei größeren Flotten erheblich; zusätzliche Kosten für Hardware, Google-Support, Anthos-Komponenten und optionale Services machen die TCO-Kalkulation komplex. Marktbeobachtungen bestätigen, dass GDC-Gesamtkosten oft über dem Marktdurchschnitt liegen.

💡 Begründung: Skala 4=Strong efficiency benefit. Die Automatisierungstiefe (Config Sync, Auto-Upgrades, zentrales Fleet-Management über viele Cluster) und die integrierten Security-Kontrollen vermeiden teure Sicherheitsvorfälle und manuelle Toil. Der Break-even liegt nach typischen Erfahrungen bei mittelgroßen Flotten (10+ Cluster) klar im positiven Bereich.

💡 Begründung: Google stellt Support-Pläne mit definierten Kontaktkanälen bereit, jedoch kein klassisches 1st-Level-Hotline-Modell wie traditionelle On-Premise-Vendoren. Kundeninterne Teams übernehmen typischerweise den initialen Support. Das entspricht einem adequaten, aber nicht starken Modell – Score 3.

💡 Begründung: Google Premium Support bietet dedizierte TAMs und Zugang zu spezialisierten Ingenieuren, was eine gute 2nd-Level-Kollaboration ermöglicht. Allerdings ist dies plan-abhängig und nicht für alle Tier verfügbar. Score 4 für gutes, aber plangebundenes Modell.

💡 Begründung: GKE/GDC ist ein Kernprodukt von Google mit aktiver Engineering-Beteiligung bei kritischen Tickets. Der Premium Support bietet dokumentierte Eskalationspfade zu Engineering-Teams. Score 4, da es sich um ein gutes Engineering-Eskalationsmodell handelt, jedoch keine garantierten Fix-Timelines für alle Szenarien bekannt sind.

💡 Begründung: Das Gesamtkonzept ist umfassend mit mehreren Stufen, weltweiter Abdeckung und API-Integration für Ticket-Bridges. Leider ist der Sprachsupport außerhalb von Englisch begrenzt, und nicht alle Features sind in Basis-Plänen enthalten. Score 4 als starkes, aber nicht perfektes Konzept.

💡 Begründung: Dokumentierte, nach Priorität gestaffelte Response-SLAs sind vorhanden und im Premium-Bereich enterprise-tauglich. Fehlende Lösungszeit-Garantien verhindern den Höchstscore. Score 4 als gutes SLA-Angebot mit klaren Response-Zeiten.

💡 Begründung: 24/7-Abdeckung für kritische Cases ist Standard im Premium und Enhanced Support. Regionale Unterschiede bestehen vornehmlich beim Sprachsupport und TAM-Zonen. Score 4 für gute, aber nicht vollkommen gleichwertige globale Abdeckung.

💡 Begründung: Das Trainingsökosystem von Google ist eines der umfangreichsten im Cloud-Bereich mit strukturierten Lernpfaden, Hands-on-Labs, Zertifizierungen und rollenspezifischen Kursen. Das Feature 'Google Cloud Training & Certification (Enablement)' ist explizit als Stärke gelistet. Score 5 ist gerechtfertigt.

💡 Begründung: Container-Optimized OS ist ein read-only Root-Filesystem mit automatischen Updates, aber kein klassisches A/B-Partitions-Immutable-OS wie Talos oder Flatcar. SSH kann deaktiviert werden, ist aber nicht technisch deaktiviert. COS ist kein eigenständiges Portfolio-Produkt mit vollständiger API-Steuerung und SBOM. Dies entspricht am ehesten Score 2: unterstütztes/eigenes eingeschränktes OS ohne vollständige Erfüllung der immutablen Kriterien.

💡 Begründung: GDC on Bare Metal nutzt ein eigenes Admin-Cluster-basiertes Provisioning-Modell, das jedoch kein standardisierter CAPI-Provider ist. BMC/IPMI-Integration ist eingeschränkt und nicht vollständig deklarativ per YAML steuerbar. Wipe/Reprovision-Zyklen erfordern manuelle Eingriffe. Score 2 ist angemessen: teilweise automatisiert, kein nativer CAPI-Provider im Portfolio.

💡 Begründung: Google hat Cilium in GKE integriert (GKE Dataplane V2 basiert auf Cilium/eBPF), jedoch ist dies keine eigenentwickelte CNI-Lösung aus dem Google-Portfolio. Für Bare-Metal-GDC ist Cilium als Option verfügbar, aber BGP-natives Peering zu ToR-Switches ohne Overlay ist nicht als vollständig eigenes Produkt dokumentiert. Score 2: CNI mit BGP-Unterstützung als integrierte Partner-Komponente, nicht als eigenständiges Google-Portfolioprodukt.

💡 Begründung: Generisches Monitoring mit etcd-Metriken ist über Google Cloud Managed Service for Prometheus verfügbar, und NVMe-Tuning-Empfehlungen existieren in der Dokumentation. Automatisches Alerting bei Schwellwertüberschreitung ist konfigurierbar, aber kein dediziertes etcd-Monitoring-Produkt mit NVMe-spezifischen Dashboards. Score 3 ist angemessen: generisches Monitoring mit etcd-Metriken, NVMe-Tuning über Dokumentation.

💡 Begründung: Die GDC Air-Gapped Edition ist ein dediziertes Produkt für hochsichere, vollständig isolierte Umgebungen. Lokale Container-Registry und Image-Mirroring sind integriert. Google dokumentiert Offline-Bundle-Prozesse. Ein vollständig automatisierter air-gap-Compliance-Report ist nicht öffentlich nachgewiesen, daher Score 4 statt 5.

💡 Begründung: Es gibt kein Google-eigenes Chaos-Engineering-Tool im Portfolio. Weder GDC noch GKE Enterprise noch Anthos enthält ein natives Chaos-Engineering-Modul. Dies entspricht eindeutig Score 1: ausschließlich manuelle Fehlerszenarien oder externe Drittprodukte ohne Portfolio-Integration.

💡 Begründung: Google dokumentiert Multi-Site-Referenzarchitekturen für GKE Enterprise mit unabhängigen Clustern und GitOps-Synchronisation via Anthos Config Management. etcd-Quorum-basiertes Split-Brain-Design ist inhärent vorhanden. Fencing-Mechanismen und automatisches Failover sind dokumentiert. Kein öffentlich bekannter KRITIS-spezifischer Referenzkunde, daher Score 4.

💡 Begründung: GDC Bare Metal unterstützt lokalen Storage über CSI-Treiber, aber kein eigenes SDS-Produkt wie Rook/Ceph oder DRBD/LINSTOR. Geo-Replikation zwischen Standorten erfordert Drittprodukte. Dies entspricht Score 2: SDS als unterstütztes Drittprodukt, keine eigene Google-SDS-Lösung im Portfolio.

💡 Begründung: GKE Dataplane V2 nutzt eBPF für Netzwerksicherheit, und Google bietet Security-Monitoring-Funktionen. Ein Tetragon-äquivalentes eigenständiges eBPF-Intrusion-Detection-Produkt mit Enforce-Modus und BSI-Konformitätsdokumentation ist nicht als dediziertes Google-Portfolio-Produkt bekannt. Conservativ bewertet: Score 3 für eBPF-Monitoring mit Detect-Funktionalität ohne formal nachgewiesene BSI-Konformität.

💡 Begründung: Google bietet Binary Authorization (Signaturprüfung/Cosign), Artifact Registry mit Vulnerability Scanning (CVE-Matching), SBOM-Unterstützung und einen Admission Controller. Diese Komponenten sind aus dem eigenen Portfolio und decken die wesentlichen Anforderungen ab. Air-gap-Betrieb ist möglich, CVE-Feed-Updates erfordern manuelle Schritte. Kein öffentlich nachgewiesener KRITIS-Referenzkunde, daher Score 4.

💡 Begründung: Physische Compute-Isolation auf dedizierten Nodes, VLAN-Trennung und RBAC mit OPA Gatekeeper sind im Portfolio vorhanden. Automatisierter Compliance-Report für BSI-Audits ist über Cloud Audit Logs und Config Management verfügbar. VLAN/VRF bis ToR-Ebene ist nicht nativ im CNI-Produkt, sondern erfordert externe Netzwerkkonfiguration. Score 4 ist angemessen, kein KRITIS-Referenzkunde öffentlich bekannt.

💡 Begründung: Config Sync (Teil von Anthos Config Management) ist ein eigenentwickeltes Google-Portfolio-Produkt mit automatischer Drift-Erkennung und -Korrektur. Air-gap-Betrieb mit lokalem Git-Server ist dokumentiert und unterstützt. Drift-Erkennungsintervalle sind konfigurierbar (typisch unter 5 Minuten). Kein öffentlich nachgewiesener KRITIS-Referenzkunde, und air-gap erfordert Konfigurationsaufwand, daher Score 4.

💡 Begründung: GDC verwendet ein proprietäres deklaratives Management-System, nicht Cluster API als primären Mechanismus. Es gibt CAPI-Kompatibilitätsarbeit, aber kein vollständig CAPI-basierter Node-Lifecycle aus eigenem Portfolio ist dokumentiert. Vereinzelte Skripte und manuelle Schritte können erforderlich sein, was Stufe 3 entspricht.

💡 Begründung: Google bietet Metriken (Prometheus-kompatibel über Managed Prometheus) und Logging als eigene Dienste, jedoch ist die air-gap-Tauglichkeit eingeschränkt und IPMI/SMART-Unterstützung fehlt nativ. Traces via OpenTelemetry sind integrierbar, aber kein vollständiger korrelierter Stack aus eigener Hand für air-gapped Bare-Metal. Dies entspricht Stufe 3.

💡 Begründung: GKE Security Posture Management bietet CIS K8s Benchmarking, aber BSI-Grundschutz-Mapping fehlt explizit. Kontinuierliches Scanning ist teilweise möglich, Export für BSI-Audits ist nicht direkt als Feature dokumentiert und muss manuell konfiguriert werden. Stufe 3 ist angemessen.

💡 Begründung: Google Cloud KMS existiert als Dienst, ist aber cloud-abhängig. Für air-gapped GDC gibt es KMS-Plugin-Unterstützung für externe HSMs, aber kein eigenständiges Google-Portfolio-Produkt für on-premises HSM-Integration mit automatischer Secret-Rotation. Dies entspricht Stufe 3 mit Plugin-basiertem HSM-Ansatz.

💡 Begründung: Chaos Engineering, dediziertes BGP-CNI aus eigenem Portfolio und vollständiges Bare-Metal-OS sind nicht durch Google-eigene Produkte abgedeckt. CNI basiert auf Calico/Cilium (Drittanbieter), kein eigenes Chaos-Engineering-Tool. Portfolio-Abdeckung liegt unter 70%, mehrere Drittprodukte erforderlich – Stufe 2.

💡 Begründung: Google hat Patch-Prozesse für GKE dokumentiert und stellt Updates bereit, aber ein explizites koordiniertes SLA < 72h für alle Komponenten (OS, CNI, Storage) mit air-gap-fähigen signierten Bundles ist nicht öffentlich dokumentiert. Stufe 3 ist konservativ angemessen.

💡 Begründung: Als US-amerikanisches Unternehmen hat Google keine öffentlich dokumentierten Zusagen für deutsche Sicherheitsüberprüfungen (SÜG Ü2). Ein dediziertes KRITIS-Team in Deutschland ist nicht nachgewiesen. Dies entspricht Stufe 2 – allgemeines Enterprise-Support-Team ohne KRITIS-Spezialisierung.

💡 Begründung: GDC wird im Verteidigungsbereich (US DoD Classified) eingesetzt, was air-gapped Bare-Metal belegt, aber europäischer Energiesektor/KRITIS ist nicht öffentlich nachgewiesen. Reguliertes Umfeld ja, aber kein spezifischer Energiesektor-KRITIS-Nachweis in Europa. Konservativ Stufe 2.

💡 Begründung: Google hat kein eigenes CNI-Produkt im Portfolio; Calico und Cilium sind Drittanbieter-Lösungen. BGP-Peering und BFD sind technisch möglich, aber nicht aus eigenem Portfolio. Manuelle Switch-seitige Eingriffe sind typischerweise noch erforderlich. Stufe 2 ist angemessen.

💡 Begründung: Google bietet keine NIS-2-spezifischen Meldeworkflow-Tools mit STIX/TAXII-Export aus eigenem Portfolio. Strukturierte Sicherheitsereignisse können aggregiert werden, aber die Meldeketten-Integration für BSI-Anforderungen erfordert erhebliche Eigenentwicklung. Stufe 2 ist angemessen.

💡 Begründung: GKE hat etcd-Management integriert, aber für multi-standort geo-redundante GDC-Setups mit vollautomatischer Member-Promotion und Learner-Nodes ist die Dokumentation lückenhaft. Recovery nach Standortausfall kann mehrere manuelle Schritte erfordern. Stufe 3 ist konservativ angemessen.

💡 Begründung: Anthos Service Mesh liefert mTLS/SPIFFE-basierte identitätsbasierte Segmentierung auf L4/L7, Policy-as-Code via ACM/GitOps ist vorhanden. L3 ist noch teilweise IP-basiert über Standard NetworkPolicies. Dies entspricht Stufe 4 der Bewertungsskala.

💡 Begründung: GDC on Bare-Metal unterstützt automatisiertes Provisioning und Secure Boot, aber ein vollständig nachweislich idempotenter Zyklus mit expliziter kryptografischer OS-Image-Signierung und garantierter automatischer Reintegration ohne jegliche manuelle Schritte ist nicht als eigenständiges Feature dokumentiert. Konservative Bewertung auf 3: Automatisiertes Wipe und PXE-Boot mit Secure Boot vorhanden, aber mehrere manuelle Schritte bei der Reintegration möglich.

💡 Begründung: Als US-amerikanischer Anbieter fokussiert Google primär auf internationale Standards wie ISO 27001, SOC2 und FedRAMP. Ein dediziertes BSI IT-Grundschutz-Baustein-Mapping (SYS.1.6, NET.1.1, OPS.1.1.3) für GDC ist nicht bekannt. Allgemeine Compliance-Dokumentation existiert, aber kein spezifisches IT-Grundschutz-Mapping entsprechend der Skalendefinition für Score 2.

💡 Begründung: GDC bietet keine eigenständige geo-replizierte Storage-Lösung mit vertraglich garantierten RTO/RPO-Werten für Bare-Metal. Die Plattform setzt auf externe oder CSI-kompatible Storage-Backends. Konkrete Messwerte aus Bare-Metal-Produktionsumgebungen sind nicht dokumentiert, was Score 2 (generelle Aussagen ohne konkrete Messwerte) entspricht.

💡 Begründung: ACM/Config Sync ist air-gap-fähig und unterstützt interne Git-Repositories (Gitea, GitLab CE). Commit-Signierung ist möglich, wird aber nicht explizit auf GitOps-Controller-Ebene erzwungen – dies entspricht Score 3. Das 4-Augen-Prinzip ist nur prozessual oder via Git-Repository-Einstellungen umsetzbar, nicht durch eigene Portfolio-Funktionen technisch erzwungen.

💡 Begründung: GKE Enterprise/GDC dokumentiert Upgrade-Kanäle (Rapid, Regular, Stable) mit Kompatibilitätsmatrizen, automatisierten Pre-Upgrade-Checks und Rollback-Fähigkeiten. Die Koordination über alle Schichten (CNI, Storage, Monitoring) ist gut dokumentiert. Für vollständig automatischen Rollback ohne jeglichen manuellen Eingriff gibt es Einschränkungen, daher Score 4.

💡 Begründung: Secure Boot ist vorhanden (entspricht Score 2), aber eine vollständige TPM 2.0 Remote Attestierung mit PCR-Sollwert-Management als erzwungene Bedingung für die Cluster-Aufnahme ist nicht als native GDC-Funktion dokumentiert. Für eine höhere Bewertung wäre eine explizite TPM 2.0 Attestierung in der Provisionierungsstrecke notwendig.

💡 Begründung: Der GDC-Observability-Stack deckt Kubernetes-Metriken gut ab, aber IPMI/Redfish, NVMe SMART und NIC-Fehlerstatistiken sind nicht nativ integriert. Predictive Maintenance ist nicht im Portfolio. Dies entspricht Score 2: Nur Kubernetes-Metriken, Hardware-Level-Monitoring erfordert separate Drittsoftware.

💡 Begründung: GDC/GKE Enterprise bietet keine natives PAM-Produkt mit JIT-Zugriff, Genehmigungsworkflow und Session Recording für air-gapped Cluster-Administration. RBAC und Workload Identity sind vorhanden, aber kein vollständiges PAM-Konzept. Score 2: Grundlegendes Zugriffsmanagement ohne JIT, Session Recording nur mit externer Komponente.

💡 Begründung: Formale Common Criteria Zertifizierungen (EAL2+ oder höher) oder BSI-Zulassungen für GDC-Komponenten sind nicht bekannt. Google fokussiert auf Cloud-orientierte Compliance-Frameworks (FedRAMP High, ISO 27001). Dies entspricht Score 2: Allgemeine Compliance-Aussagen ohne formale Komponentenzertifizierungen nach CC oder BSI-Zulassung.

💡 Begründung: Google hat Fortschritte bei Supply Chain Security (SLSA, SBOM), aber kein öffentlich dokumentiertes, kontinuierliches geografisches Lieferketten-Monitoring mit BSI-konformer Drittlands-Analyse. Als US-amerikanisches Unternehmen mit weltweiten Entwicklungsstandorten (inkl. Länder mit geopolitischen Risiken) ist Score 2 angemessen: keine systematische geografische Lieferketten-Analyse.

💡 Begründung: Die GDC Air-Gapped Edition ist ein Kernprodukt, das explizit für den Betrieb ohne externe Verbindungen entwickelt wurde. GitOps aus lokalem Cache, lokales Secrets Management und lokale Observability sind dokumentiert. Ein definiertes Wiedervereinigungsverfahren nach WAN-Wiederherstellung ist weniger explizit dokumentiert, daher konservativ Score 4 statt 5.

💡 Begründung: GDC deckt die Kernszenarien (lokaler Cluster-Betrieb, DNS-Fallback, cert-manager für PKI) ab, aber spezifische Blackout-Szenarien wie GPS-NTP-Fallback, vollständiges OIDC-Fallback und automatische Selbstheilung ohne Operator sind nicht als vollständig dokumentierte, getestete eigene Portfolio-Lösungen bekannt. Score 3 reflektiert vorhandene Fallbacks mit Lücken bei einzelnen kritischen Abhängigkeiten.

💡 Begründung: GDC/GKE Enterprise bietet Standard-Audit-Logging (Cloud Audit Logs, immutable Storage-Optionen in GCS), aber keine explizite TR-ESOR-Konformität, keine kryptografisch verketteten Logs mit Merkle-Tree-Strukturen als Eigenprodukt, keine qualifizierten eIDAS-Zeitstempel und keine nachgewiesene BSI-Zertifizierung. Dies entspricht Skala 2: Standard-Log-Archivierung ohne kryptografische Sicherung gegen Manipulation im TR-ESOR-Sinne.

💡 Begründung: GDC Bare-Metal nutzt einen eigenen Cluster-Lifecycle-Manager, der PXE-Boot und grundlegende Server-Provisionierung unterstützt, jedoch ist keine eigenständige, deklarative OOB-Management-Komponente mit dokumentierter Multi-BMC-Hersteller-Validierung (iDRAC, iLO, AMI) und CAPI-Integration bekannt. Wipe-and-Reprovision erfordert manuelle Schritte außerhalb einer deklarierten OOB-Pipeline. Dies entspricht Skala 2: generische IPMI-Tool-Nutzung ohne Portfolio-Eigenkomponente.

💡 Begründung: Das CNI-Ökosystem von GDC (Calico/Cilium als typische Optionen, kein proprietäres CNI-Eigenprodukt mit OT-Fokus) bietet Standard-NetworkPolicies auf L3/L4, aber explizite Layer-2-Multicast-Unterstützung für GOOSE und OT-Protokoll-spezifische Funktionen sind nicht dokumentiert. Es gibt keine bekannte Referenzarchitektur für Energiesektor-OT-Protokolle auf GDC. Dies entspricht Skala 2: Standard-NetworkPolicies ohne OT-Protokoll-Unterstützung, Layer-2-Multicast nicht nativ unterstützt.

💡 Begründung: Während Google SLSA-Framework-Unterstützung anbietet und Open-Source-Basiskomponenten nutzt, sind proprietäre GDC-Kernkomponenten nicht über einen EU-ansässigen Escrow-Anbieter abgesichert, und es gibt keine bekannte vertragliche Escrow-Vereinbarung für KRITIS-Kunden. Reproduzierbare Builds nach Reproducible-Builds-Spezifikation sind nicht formal zertifiziert. Dies entspricht Skala 2: Escrow nur auf explizite Nachfrage möglich, keine formale Reproducible-Builds-Strategie für alle Kernkomponenten.

💡 Begründung: COS bietet grundlegende Immutability und automatische Updates, jedoch sind vollständig atomare Transaktionen mit garantiertem automatischem Rollback nicht als prominentes Feature dokumentiert. Für Bare-Metal-Deployments ist die OS-Wahl eingeschränkter. Score 3 (Minimum erfüllt) ist angemessen.

💡 Begründung: GDC Bare Metal bietet deklaratives Cluster-Provisioning via bmctl und YAML-Manifeste, deckt aber nicht alle Aspekte wie vollständige IPMI/Redfish-Integration oder umfassende Hardware-Inventarisierung ab. Dies erfüllt das Minimum, hat aber erhebliche Lücken gegenüber Best-in-Class. Score 3 erscheint angemessen, konservativ bewertet.

💡 Begründung: Das automatisierte Cluster-Upgrade-Feature ist explizit als bekanntes Feature gelistet. Fleet-Management über GKE Enterprise ermöglicht deklaratives Lifecycle-Management. Kleine Einschränkungen bestehen beim vollständig automatisierten Dekommissionierungs-Workflow in Air-Gap-Szenarien, daher Score 4 statt 5.

💡 Begründung: Alle Kernkomponenten sind explizit als Features gelistet: GKE Enterprise Fleet Management, Anthos Config Management, Policy Controller (OPA Gatekeeper) und Config Sync. Dies entspricht einer vollständigen, ausgereiften Best-in-Class-Lösung für Multi-Cluster-Management. Score 5 ist gerechtfertigt.

💡 Begründung: GitOps-basierte Policy-Synchronisation via Anthos Config Management ist explizit als Kernfeature gelistet und gilt als eines der Hauptalleinstellungsmerkmale der Plattform. Die Unterstützung umfasst Multi-Cluster, Multi-Tenant und Namespace-spezifische Konfigurationen. Score 5 ist gerechtfertigt.

💡 Begründung: Binary Authorization mit Cosign-Integration und SLSA-Framework-Unterstützung sind explizit als Features gelistet, kombiniert mit OPA Gatekeeper für Admission Control. Dies deckt alle Aspekte der Anforderung vollständig ab und entspricht Best-in-Class. Score 5 ist angemessen.

💡 Begründung: Während Audit-Logging und Service-Mesh-Telemetrie vorhanden sind, fehlt eine explizite native Runtime-Security mit Verhaltensbaselines und automatischer Anomalieerkennung. Google Security Command Center kann ergänzt werden, ist aber nicht Teil des GDC-Kernprodukts für On-Premise/Air-Gap. Konservativ Score 3.

💡 Begründung: Im Cloud-verbundenen Betrieb ist CVE-Scanning über Artifact Registry/Analysis verfügbar. Im Air-Gap-Betrieb sind die Möglichkeiten für natives integriertes Scanning deutlich eingeschränkter. Da der Fokus auf On-Premise/Air-Gap liegt, ist Score 3 konservativ aber angemessen.

💡 Begründung: Anthos Service Mesh (Istio) für L7-Policies ist explizit gelistet. GDC Bare Metal unterstützt BGP für Unternehmensnetze. Egress-Kontrolle ist über Service Mesh und Network Policies abdeckbar. Kleine Lücken bei nativen dedizierten Egress-Firewall-Features ohne Service Mesh rechtfertigen Score 4 statt 5.

💡 Begründung: Integrierter cloud-nativer verteilter Storage mit Geo-Redundanz und Stretch-Cluster ist kein dokumentiertes Feature von GDC. Die Plattform setzt auf externe Storage-Backends via CSI-Treiber. Dies stellt eine erhebliche Lücke dar, weshalb Score 2 angemessen ist.

💡 Begründung: VM-Workload-Ausführung auf Kubernetes ist kein dokumentiertes Feature von GDC/GKE Enterprise. Im Gegensatz zu Konkurrenten wie OpenShift Virtualization oder Rancher mit KubeVirt fehlt diese Funktionalität nahezu vollständig. Score 2 (rudimentär, erhebliche Lücken) ist angemessen.

💡 Begründung: GDC Air-Gapped Edition ist als dediziertes Produkt für vollständig disconnected/air-gapped Betrieb konzipiert und explizit als erstes Feature gelistet. Dies ist ein Kernangebot des Produkts und entspricht Best-in-Class für diese Anforderung. Score 5 ist eindeutig gerechtfertigt.

💡 Begründung: Google bietet FIPS 140-2 Unterstützung für GKE/GDC über spezielle FIPS-konforme OS-Images und kryptografische Bibliotheken, jedoch ist die vollständige FIPS 140-3 Zertifizierung noch nicht für alle Komponenten ausgreift dokumentiert. Ein Score von 4 ist gerechtfertigt, da die Unterstützung gut ist und über das Minimum hinausgeht, aber Best-in-Class-Status (5) würde eine lückenlose, vollständig zertifizierte FIPS 140-3 Abdeckung aller Komponenten erfordern.

💡 Begründung: Google stellt CIS Benchmark-Compliance für GKE bereit, inklusive automatisierter Policy-Durchsetzung via OPA Gatekeeper und Config Sync. Compliance-Reporting ist über Cloud Audit Logs und Security Command Center verfügbar. BSI IT-Grundschutz ist weniger nativ integriert, weshalb Score 5 nicht vergeben wird, aber 4 ist gerechtfertigt da die Lösung die Mindestanforderung klar übertrifft.

💡 Begründung: Die GDC Air-Gapped Edition wurde explizit für vollständig autarken Betrieb entwickelt und beinhaltet eine lokale Registry. Jedoch ist die native, eigenständige Registry-Lösung weniger ausgereift als dedizierte Registry-Produkte (z.B. Harbor), und detaillierte HA-Konfiguration mit vollständigem Mirroring-Framework ist nicht immer transparent dokumentiert, daher Score 4 statt 5.

💡 Begründung: In der Cloud-verbundenen Variante ist der Observability-Stack stark, aber in Air-Gapped/On-Premises-Umgebungen ohne Internetzugang fehlt ein vollständig integrierter Stack mit Grafana und Loki ohne manuelle Drittkomponenten-Integration. Dies entspricht Score 3 (erfüllt Minimum), da Prometheus-Metriken vorhanden sind, aber Grafana-Dashboards und Log-Aggregation à la Loki zusätzliche Arbeit erfordern.

💡 Begründung: GDC ist primär eine Container-Orchestrierungsplattform ohne eigene eingebettete CI/CD-Engine. Cloud Build ist ein separater Google-Dienst und nicht nativ in GDC on-premises integriert. Tekton kann als Open-Source-Lösung installiert werden, ist aber nicht out-of-the-box Teil des Produktumfangs. Dies entspricht Score 2, da erhebliche Lücken für eine native CI/CD-Erfahrung bestehen.

💡 Begründung: Die Kombination aus nativem Kubernetes RBAC, Anthos Config Management mit Multi-Tenant Config Sync, OPA Gatekeeper für Policy-Enforcement und Workload Identity Federation stellt eine Best-in-Class Multi-Tenancy-Lösung dar. Alle genannten Anforderungselemente (RBAC, Namespace-Isolation, Ressourcenquoten) sind vollständig und ausgereift erfüllt, was Score 5 rechtfertigt.

💡 Begründung: Google als globaler Hyperscaler bietet solide Enterprise-SLAs, aber direkter deutschsprachiger First-Level-Support und nachweisliche KRITIS-Erfahrung für GDC on-premises sind nicht primär produktseitig dokumentiert, sondern werden über Partner-Ökosysteme abgedeckt. BSI IT-Grundschutz Zertifizierung für GDC ist nicht bekannt. Score 3 ist konservativ gerechtfertigt da das Minimum erfüllt wird, aber spezifische deutsche Behördenanforderungen Lücken aufweisen.

💡 Begründung: GDC on Bare Metal fokussiert auf Kubernetes-Container-Workloads mit einer optionalen VM Runtime, bietet aber keine vollständige HCI-Plattform im Sinne von VMware vSAN oder Nutanix AHV, die Storage, Compute und Networking vollständig konvergiert. Die fehlende integrierte, softwaredefinierte Storage-Schicht (kein natives Ceph oder vSAN-Äquivalent) begrenzt den Score auf 2, da erhebliche Lücken für echte HCI-Anforderungen bestehen.

💡 Begründung: MAAS, Kubernetes und Juju verfügen über vollständige, dokumentierte REST-APIs; alle wesentlichen Funktionen sind API-zugänglich. Out-of-the-box-Konnektoren für gängige Middleware-Systeme (PI, EAI, EDI-Manager) sind nicht im Kernprodukt enthalten, was einen Score von 5 verhindert. Gängige Integrationen (Prometheus, Grafana, OIDC, etc.) sind vorhanden, daher Score 4.

💡 Begründung: Mit COS (Prometheus/Grafana/Alertmanager) und Kubernetes-nativen Health-Endpoints ist gutes Interface-Monitoring mit operativen Diagnosemöglichkeiten gegeben. Vollständig integriertes, speziell auf Interface-Monitoring ausgerichtetes Built-in-Tooling (z.B. dediziertes API-Gateway-Monitoring) ist nicht out-of-the-box vorhanden, weshalb Score 5 nicht erreicht wird; Score 4 ist angemessen.

💡 Begründung: Kubernetes RBAC erlaubt Custom Roles auf Namespace-/Cluster-Ebene, aber keine echte pfadbasierte Filterung innerhalb von Ressourcen. Die Kombination mit Juju-Modell-RBAC ist vorhanden, jedoch nicht als vollständig policy-gesteuertes ABAC-System. Dies entspricht eher 'Static/Flexible RBAC' auf Repository-/Namespace-Ebene, daher Score 3.

💡 Begründung: Kubernetes selbst unterstützt OIDC als Authentifizierungsmechanismus, aber automatisches User/Group-Lifecycle-Management via SCIM ist nicht nativ vorhanden. Custom Scripting gegen die Kubernetes API wäre erforderlich, was Skala-Punkt 2 entspricht.

💡 Begründung: OIDC wird unterstützt, jedoch ist kein Self-Service-UI für SSO-Konfiguration vorhanden. Die Einrichtung ist manuell und erfordert technisches Know-how (Konfiguration von kube-apiserver OIDC-Parametern). Dies entspricht eher Score 3 (Basic SSO, manuelle Konfiguration ohne Self-Service).

💡 Begründung: Die Kombination aus Kubernetes-Namespaces, RBAC und Juju-Modellen bietet granulare, permission-basierte Separation. Ein vollständiges 'Organizations'-Konzept wie bei SaaS-Plattformen fehlt, aber die technische Isolation ist stark. Score 4 ist angemessen.

💡 Begründung: Die Bewertungsskala bezieht sich auf Applikations-Metadaten-Storage (PostgreSQL, MS SQL etc.). Canonical Kubernetes nutzt etcd als Cluster-State-Store und hat kein flexibles externes DB-Backend für Applikationsmetadaten. Dies passt am ehesten zu Score 1 (Non-Standard Storage / spezifische interne Komponenten).

💡 Begründung: Ceph RadosGW bietet S3-API-Kompatibilität, was eine breite Kompatibilität ermöglicht. Vollständige native Unterstützung aller drei großen Cloud-Provider (S3, Azure Blob, GCS) ist nicht gegeben. Score 4 (S3-Compatible Gateway Support) ist korrekt.

💡 Begründung: Die Skala bezieht sich auf Artefakt-Archivierung (z.B. Package-Repository-Cleanup). Canonical Kubernetes ist kein Artefakt-Repository. Cleanup-Automatisierung für Kubernetes-Ressourcen (z.B. TTL-Controller) ist vorhanden, aber nicht als Policy-Engine für Dateiarchivierung. Score 2 ist konservativ angemessen.

💡 Begründung: MicroK8s kann auf VMs und in Containern laufen, Charmed Kubernetes läuft auch auf Hyperscalern, aber ein vendor-managed SaaS-Angebot existiert nicht. Der Fokus auf Bare-Metal On-Premise und fehlende echte SaaS-Option führt zu Score 3.

💡 Begründung: Ein vollständiger Charmed-Kubernetes-Stack mit MAAS, Ceph und Juju ist ressourcenintensiv und erfordert mehrere physische oder virtuelle Maschinen. MicroK8s reduziert den Footprint, aber für Enterprise-Setups ist der Ressourcenbedarf spürbar. Score 3 (adäquat, aber ressourcenintensiv) ist zutreffend.

💡 Begründung: Die Juju-basierende Deployment-Automatisierung ist stark und gut dokumentiert. Initiale MAAS-Konfiguration und Juju-Bootstrap erfordern manuelle Schritte, aber der Großteil ist skriptbasiert automatisiert. Score 4 (Scripted Installation mit einigen manuellen Prerequisite-Schritten) ist angemessen.

💡 Begründung: Charmed Ceph mit Stretch-Cluster-Unterstützung ermöglicht echte Multi-Standort-Replikation mit zentralem Daten-Repository. Dies entspricht 'Asynchronous Replication' bzw. sogar aktiv-aktiv-Szenarien. Score 4 ist angemessen; vollständige Federation mit intelligentem Edge-Caching wie bei spezialisierten Artefakt-Repositories ist nicht das primäre Use-Case.

💡 Begründung: Bare-Metal-Kubernetes eliminiert Virtualisierungs-Overhead und ermöglicht sehr gute Latenz- und Durchsatzwerte. Ceph-Performance ist bekanntermaßen gut skalierbar, erfordert aber Tuning für optimale Ergebnisse. Score 4 (gutes Performance-Profil mit geringem Tuning-Bedarf) ist realistisch.

💡 Begründung: Kubernetes bietet ein robustes Concurrency-Modell; MAAS ermöglicht automatische Node-Bereitstellung unter Last. Score 4 statt 5, weil Bare-Metal-Skalierung langsamer als Cloud-native Elastizität ist und Tuning für sehr hohe Parallellasten erforderlich bleibt.

💡 Begründung: MicroK8s für Edge und Ceph Stretch-Cluster helfen bei verteilten Szenarien, jedoch fehlen explizite, out-of-the-box Mechanismen für Offshore-/Remote-User-Latenz-Optimierung (kein integriertes globales Caching/Proxy-Layer). Score 3 ist konservativ gerechtfertigt.

💡 Begründung: Canonical bietet kein umfassendes No-Code-UI für alle Betriebsaspekte; viele Einstellungen erfolgen deklarativ per YAML/CLI. Das entspricht Score 3: Basisanpassungen ohne Code möglich, aber fortgeschrittene Szenarien erfordern Scripting.

💡 Begründung: Das Charm-Operator-Framework ist ein offizieller, dokumentierter Erweiterungspunkt für kundenspezifische Entwicklung. Score 4 statt 5, weil der Extension-Support-Scope für custom Charms begrenzt ist und tiefe Produktänderungen weiterhin nicht offiziell supported werden.

💡 Begründung: Enterprise-RBAC und externe Identity-Integration sind gut unterstützt. Score 4, da explizite 'Guest/External User'-Konzepte wie bei dedizierten DevOps-Plattformen (z.B. Azure DevOps) fehlen und manuelles Setup für Offshore-Governance nötig ist.

💡 Begründung: Juju Operator Framework und Kubernetes-native Extension-Punkte (Webhooks, Custom Controllers, CNI/CSI Plugins) ermöglichen tiefe side-by-side Customization. Score 4, da ein zentrales Plugin-Marketplace/Registry fehlt und Tiefe der nativen Extensions für bestimmte Anwendungsfälle begrenzt bleibt.

💡 Begründung: Deklaratives Juju-Modell + MAAS-API erlaubt hohe Konsistenz und Automatisierbarkeit. Score 4 statt 5, weil Multi-Team-Governance über mehrere Umgebungen hinweg noch manuelle Koordination und konsequente IaC-Disziplin erfordert, kein zentrales Policy-as-Code-Dashboard vorhanden.

💡 Begründung: Vollständige Open-Source-Verfügbarkeit aller Kernkomponenten. Score 5 ist gerechtfertigt gemäß Skala: 'Fully open source with broad code access and practical ability to review/change core behavior.'

💡 Begründung: Transparenter Release-Kalender, fast Security-Handling via Livepatch/ESM und strukturierte Upgrade-Mechanismen. Score 4, da Bare-Metal-Upgrade-Testing kundenspezifischen Validierungsaufwand erfordert und nicht alle Komponenten gleich reibungslos upgradebar sind.

💡 Begründung: Starke HA- und Recovery-Konzepte für alle Schichten des Stacks. Score 4 statt 5, da Backup/Restore-Prozesse für etcd und persistente Daten operational komplex bleiben und keine vollständig automatisierte One-Click-Disaster-Recovery out-of-the-box existiert.

💡 Begründung: Rolling Upgrades sind ein dokumentiertes, unterstütztes Pattern. Score 4, da bei Bare-Metal-Szenarien physische Abhängigkeiten und Drain-Zeiten unvermeidliche kurze Unterbrechungen pro Node bedeuten können; Zero-Downtime ist nicht für alle Workload-Typen garantiert.

💡 Begründung: Im On-Premise/Self-Managed-Modell gibt Canonical keine Verfügbarkeits-SLA für die laufende Plattform; nur Support-SLAs (Reaktionszeiten) sind verfügbar. Score 2 entspricht 'Limited formal SLA relevance for typical deployment model'.

💡 Begründung: Die Plattform richtet sich explizit an erfahrene Infrastruktur-Engineers. Kein einheitliches UI für alle Kernaufgaben; MAAS-Web-UI, Juju-CLI und kubectl müssen kombiniert werden. Dies entspricht laut Skala einer steilen Lernkurve mit häufigem Bedarf an Anleitung (Score 2).

💡 Begründung: Mehrere Tools mit unterschiedlichem Look-and-Feel und keiner übergreifenden Theming- oder Personalisierungsmöglichkeit. Dies entspricht laut Skala einer inkonsistenten UX über Bereiche hinweg (Score 2).

💡 Begründung: Guidance erfolgt primär dokumentationsgetrieben ohne nennenswerte In-Product-Assistenten für komplexe Setups. Laut Skala minimal guided UX mit vorwiegend manuellem Expertenbetrieb (Score 2).

💡 Begründung: Admin-Workflows sind im MAAS-UI erkennbar abgebildet, aber Juju-Operationen und Charmed-Kubernetes-Tasks erzeugen Friction. Für Entwickler kaum eigene UX-Optimierung. Entspricht laut Skala 'adequate fit with some friction' (Score 3).

💡 Begründung: CLI-First-Ansatz bietet Power-Usern grundlegende Produktivität durch Scripting und API, jedoch keine reichen Keyboard-Shortcuts oder erweiterte Such-/Filterkapazitäten im UI. Laut Skala 'basic productivity functions available' (Score 3).

💡 Begründung: Keine dokumentierten Personalisierungsoptionen für Endnutzer auf Theme-, Layout- oder Verhaltensebene. Entspricht laut Skala 'almost no user-level adaptation' (Score 1).

💡 Begründung: Keine bekannte umfassende UI-Lokalisierung oder Sprachumschaltung in MAAS oder Juju. Praktisch englischsprachige Oberflächen mit minimalen Lokalisierungskontrollen (Score 2).

💡 Begründung: Kein bekanntes Accessibility-Programm oder WCAG-Konformitätsdokumentation für MAAS oder Juju-UI. CLI bietet immanente Keyboard-Nutzung, aber für das UI ist nur limitierter inklusiver Interaktionssupport erkennbar (Score 2).

💡 Begründung: Das Produkt ist eine Infrastrukturplattform, keine Datenverwaltungslösung. MAAS bietet eine API als zentrale Quelle für Infrastrukturdaten (Score-Element vorhanden), aber für Anwendungsdaten und externe Leading-Source-Systeme gibt es keine native Unterstützung. Anpassungen sind erforderlich, daher Score 3.

💡 Begründung: Als On-Premise-Lösung hat der Kunde vollständige Kontrolle über den Serverstandort (EU-Rechenzentrum möglich). Hyperscaler-Support (Azure, AWS) ist vorhanden. Kleinere Einschränkungen bestehen bei spezifischen regulierten Cloud-Regionen ohne kundenseitige Steuerung, daher Score 4.

💡 Begründung: Verschlüsselung ist für alle wesentlichen Komponenten verfügbar, jedoch nicht überall standardmäßig aktiviert ohne explizite Konfiguration (z.B. Ceph-Encryption muss aktiviert werden). FIPS-Unterstützung erhöht die Bewertung. Deployment-abhängige Aspekte verhindern Score 5, daher Score 4.

💡 Begründung: Da es sich um eine On-Premise-Infrastrukturlösung handelt, hat Canonical keinen Zugang zu personenbezogenen Daten, was positiv ist. Jedoch fehlen integrierte Tools für Datenlöschung, Dateninventarisierung und vollständige DSGVO-Governance. Die Compliance-Nachweise für BDSG-spezifische Anforderungen sind begrenzt. Governance-Evidenz ist eingeschränkt, daher Score 3.

💡 Begründung: Es gibt Sicherheitszertifizierungen (FIPS 140-2, CIS-Hardening, DISA-STIG für Ubuntu), aber eine klare ISO 27001-Zertifizierung von Canonical als Unternehmen oder für den Managed-Service ist nicht eindeutig öffentlich nachweisbar. Konservative Bewertung aufgrund fehlender klarer Dokumentation, daher Score 3.

💡 Begründung: Als vollständig Open-Source-basierte On-Premise-Lösung bietet das Produkt maximale Datenportabilität ohne Vendor-Lock-in. Alle Schichten (Infrastruktur via MAAS-API, Storage via Ceph, Kubernetes-Workloads via Standard-APIs) unterstützen Export und Import. Operatives Tooling (kubectl, MAAS-CLI, Juju) ermöglicht auch Bulk-Operationen, daher Score 5.

💡 Begründung: Kubernetes selbst ist portabel, aber das gesamte Lifecycle-Management über Juju-Operatoren und MAAS als Provisioning-Layer erzeugt moderate Abhängigkeiten. Ein Austausch würde erheblichen Aufwand erfordern, ist aber prinzipiell möglich – daher Score 3 (moderate lock-in).

💡 Begründung: Canonical hat über 15 Jahre Erfahrung mit Ubuntu und den zugehörigen Tools; die Mitarbeiterfluktuation ist für ein Unternehmen dieser Größe überschaubar. Kein perfektes Score-5, da Canonical mit ca. 500–700 Mitarbeitern kleiner ist als Hyperscaler und gewisse Kontinuitätsrisiken bestehen.

💡 Begründung: Verglichen mit Cloud-basierten oder stärker automatisierten Lösungen ist der Onboarding-Aufwand für den vollständigen Canonical-Stack auf Bare-Metal hoch. MAAS-Netzwerkkonfiguration, Juju-Bootstrap und Charmed-Kubernetes-Deployment erfordern tiefes Fachwissen – Score 2 (long setup time).

💡 Begründung: Canonical hat nachgewiesene Enterprise-Deployments, aber das Professional-Services-Team ist kleiner und weniger breit aufgestellt als bei großen Systemintegratoren. Für spezifische Canonical-Technologien gut, für komplexe Enterprise-Transformationen mit vielen Integrationspunkten nur adequate – Score 3.

💡 Begründung: Canonical ist profitabel und finanziell stabil, jedoch deutlich kleiner als Red Hat (IBM), SUSE oder VMware (Broadcom). Die fehlende Börsennotierung und die moderate Unternehmensgröße rechtfertigen Score 3 (mid-sized supplier with some risk).

💡 Begründung: Canonical operiert global, aber die physische regionale Präsenz und lokale Supportkapazitäten sind begrenzt im Vergleich zu Anbietern mit dichten Niederlassungsnetzen. Für globale Enterprise-Rollouts mit lokalen Anforderungen ist dies ein moderates Risiko – Score 3.

💡 Begründung: Es gibt weder starke Synergien noch bekannte Konflikte mit typischen strategischen Programmen. Die Lösung ist applikationsagnostisch, was eine neutrale Einschätzung rechtfertigt – Score 3 (neutral dependency position).

💡 Begründung: Die Produktentwicklung bei Canonical folgt klar agilen Prinzipien mit kurzen Release-Zyklen (Ubuntu LTS alle 2 Jahre, Kubernetes-Releases eng getaktet). Juju-Operatoren und GitOps-kompatible Workflows unterstützen moderne Delivery-Methoden gut – Score 4.

💡 Begründung: Die Lösung ist technisch mächtig, aber komplex: MAAS-Einrichtung, Juju-Controller, Charm-Konfiguration und Ceph-Planung erfordern spezialisiertes Know-how. Für On-Premise/Air-Gap-Deployments steigt der Initialaufwand weiter. Die Skala bewertet hohen Setup-Aufwand mit Score 2, was hier zutreffend ist.

💡 Begründung: Charmed Kubernetes mit Juju ist ein mächtiges, aber lernintensives Framework. Custom Charms, MAAS-Netzwerk-Fabric und Ceph-Konfiguration für produktive Umgebungen bedeuten hohen Implementierungsaufwand. Skala: 2=High implementation effort passt hier.

💡 Begründung: Die Automatisierungsfeatures (Juju Operators, Livepatch, deklarative Upgrades) senken den operativen Aufwand gegenüber einem manuellen Setup deutlich. Dennoch ist ein Team mit Canonical-spezifischem Know-how für Betrieb und Fehlerbehebung erforderlich. Moderate operating effort (Score 3) ist daher angemessen.

💡 Begründung: Das knotenbasierte Ubuntu Pro Modell ist nachvollziehbar und kalkulierbar. MAAS und Juju sind Open Source ohne Lizenzkosten. Canonical veröffentlicht Preise transparent. Leicht über Marktschnitt für Enterprise-Support, aber keine intransparenten Zusatzkosten. Score 4 ist gerechtfertigt.

💡 Begründung: Die Automatisierungstiefe des Canonical-Stacks (MAAS-Automation, Juju Day-2, Livepatch, COS-Observability) liefert nachweislich starke operative Effizienzgewinne nach der initialen Lernkurve. Score 4 (Strong efficiency benefit) ist passend; Score 5 wird durch die verbleibende Betriebskomplexität verhindert.

💡 Begründung: Canonical bietet zwar professionelle Support-Verträge mit definierten Eskalationswegen, jedoch fehlt eine klassische telefonische 24/7-Hotline als primärer 1st-Level-Kanal. Der Zugang erfolgt vorwiegend über das Support-Portal, was für Enterprise-Kunden mit Hotline-Anforderungen eingeschränkt wirkt. Score 3 gemäß Skala 'Adequate support model'.

💡 Begründung: Canonical verfügt über ein gut dokumentiertes Support-Modell mit Eskalation zu produktspezifischen Experten für Kubernetes, MAAS und Ceph. Die Zusammenarbeit mit dem Kunden-IT-Team im 2nd-Level ist etabliert, jedoch sind die Prozesse stärker portal-zentriert als bei einigen Mitbewerbern. Score 4 gemäß 'Good second-level vendor collaboration'.

💡 Begründung: Canonical hat einen klar definierten 3rd-Level-Prozess mit eigenen Engineering-Teams für alle Kernkomponenten des Stacks. Bugs werden über Launchpad öffentlich verfolgt, und Support-Verträge erlauben direkte Eskalation zu Engineers. Dies entspricht Score 4 ('Good engineering escalation path'), da der Prozess gut dokumentiert, aber nicht immer mit explizit garantierten Fix-Timelines versehen ist.

💡 Begründung: Das Canonical-Support-Konzept ist gut strukturiert mit klaren Tiers, globalem Angebot und dokumentierten Prozessen. Weltweiter Support ist vorhanden, jedoch ist die Sprachunterstützung primär auf Englisch fokussiert, und die Ticket-Bridge-Integration erfordert API-Nutzung ohne out-of-the-box Konnektoren zu gängigen ITSM-Tools. Score 4 gemäß 'Strong support concept'.

💡 Begründung: Die SLA-Struktur ist klar dokumentiert und für Enterprise-Anforderungen geeignet, insbesondere im Advanced-Tier. Nicht alle Tiers bieten gleich starke SLAs (Standard-Plan ohne 24/7 für kritische Issues). Dies entspricht Score 4 ('Good SLA offering') – stark, aber nicht auf dem Niveau von Anbietern mit noch granulareren oder kundenindividuell verhandelbaren SLAs.

💡 Begründung: 24/7-Abdeckung ist im Advanced-Tier verfügbar, und Canonical ist als globales Unternehmen mit verteilten Teams aufgestellt. Der Standard-Tier bietet jedoch nur Business-Hours-Support, was eine Einschränkung darstellt. Insgesamt Score 4 ('Good regional coverage'), da globale 24/7-Abdeckung vorhanden, aber tier-abhängig.

💡 Begründung: Canonical hat ein breites Trainingsangebot mit unterschiedlichen Formaten (Online, Webinar, In-Person auf Anfrage) und zielgruppenspezifischen Inhalten für Administratoren und Entwickler. Die Dokumentation ist für alle Kernkomponenten (MAAS, Juju, K8s, Ceph) sehr umfangreich. Score 4 ('Strong documentation and training offering') – lediglich das formale Zertifizierungsprogramm ist weniger prominent als bei einigen Mitbewerbern.

💡 Begründung: Ubuntu Core ist ein eigenes Canonical-Produkt mit erhöhter Immutabilität und transaktionalen Snap-Updates, aber SSH ist weiterhin möglich und der Update-Mechanismus ist nicht identisch mit klassischen A/B-Image-Ersetzungen wie bei Talos. SBOM-Unterstützung ist eingeschränkt. Dies entspricht eher Score 2: Immutables OS als unterstütztes/eigenes Produkt, aber mit eingeschränkter API-only-Steuerung und nicht vollständig deaktiviertem SSH im Normalbetrieb.

💡 Begründung: MAAS selbst ist ein starkes eigenes Tool für Bare-Metal, aber der dedizierte CAPI-Provider für MAAS ist ein Community-Projekt bzw. nicht im selben Reifegrad wie z.B. Tinkerbell bei Equinix. Die Provisionierung ist weitgehend deklarativ über MAAS API, BMC-Integration ist nativ vorhanden, aber die volle CAPI-Integration mit demonstrierbarem Wipe/Reprovision-Zyklus ist eingeschränkt dokumentiert. Score 3 ist angemessen.

💡 Begründung: Cilium ist nicht von Canonical entwickelt oder akquiriert, sondern wird als unterstützte Konfiguration angeboten. Der overlay-freie BGP-Betrieb ist mit Cilium möglich, aber dies entspricht gemäß Skala Score 2: CNI mit BGP-Unterstützung als Partner-/Drittprodukt, kein eigenes CNI im Portfolio.

💡 Begründung: COS bietet generisches Monitoring mit etcd-Metriken und konfigurierbarem Alerting, aber kein dediziertes etcd-NVMe-Performance-Tooling mit spezifischen IOPS/Latenz-Schwellwerten und automatischer Eskalation. Dies entspricht Score 3: Generisches Monitoring mit etcd-Metriken, NVMe-Tuning über Runbooks, kein automatisches Alerting produktiv nachgewiesen.

💡 Begründung: Der gesamte Canonical-Stack ist explizit als air-gap-fähig dokumentiert und produktiv einsetzbar. MAAS unterstützt lokale Image-Stores, Juju unterstützt offline-Betrieb, ein lokaler Snap-Store kann konfiguriert werden. Ein vollständig automatisiertes Bundle-Export/Import mit air-gap-Compliance-Report ist nicht in dem Maße nachgewiesen wie für Score 5 erforderlich, daher Score 4.

💡 Begründung: Es gibt keinen Hinweis auf ein eigenes Chaos-Engineering-Tool von Canonical. Dies entspricht eindeutig Score 1: Kein Chaos-Engineering im Portfolio.

💡 Begründung: Charmed Ceph Stretch-Cluster ist ein dokumentiertes Feature mit Quorum-Witness-Unterstützung. Referenzarchitekturen für Multi-Site sind vorhanden. Ein KRITIS-spezifischer Referenzkunde ist nicht öffentlich nachweisbar, daher Score 4 statt 5.

💡 Begründung: Charmed Ceph ist ein eigenes Canonical-Produkt mit Stretch-Cluster-Unterstützung und nahe-synchroner Replikation. Automatisches Failover ist implementiert, aber vereinzelte manuelle Schritte bei komplexen Failover-Szenarien können erforderlich sein. Spezifische Latenz-Overhead-Dokumentation für < 5 ms bei 50 ms RTT ist nicht klar belegt, daher Score 4.

💡 Begründung: Es gibt kein Canonical-eigenes eBPF-Sicherheitsprodukt. AppArmor und Seccomp sind klassische Kernel-Mechanismen, kein eBPF-IDS. Tetragon ist ein CNCF-Projekt von Isovalent/Cisco, nicht Canonical. Dies entspricht Score 2: eBPF-Monitoring als unterstütztes Drittprodukt mit eingeschränkter Audit-Trail-Tiefe, wobei dies konservativ bewertet wird.

💡 Begründung: Canonical liefert Teile der Supply-Chain-Security (CVE-Scanning via USN/ESM, paketbasierte SBOMs), aber Cosign-Integration und ein dedizierter Admission Controller für Image-Verifikation sind nicht als eigenständige Portfolio-Produkte verfügbar. Lücken werden durch konfigurierbare Drittprodukte gefüllt. Score 3 ist angemessen.

💡 Begründung: Physische Node-Isolation ist über MAAS konfigurierbar, VLAN-Management ist nativ in MAAS integriert, RBAC ist Kubernetes-nativ verfügbar. Jedoch fehlt ein eigenes Policy-Engine-Produkt für Compliance-Reporting und die VRF/ToR-Integration ist nicht nativ im CNI-Portfolio. Score 3: Logische Mandantentrennung aus Portfolio, physische Trennung über Konfigurationsempfehlungen.

💡 Begründung: Juju bietet deklaratives Operator-basiertes Management, ist aber kein klassischer GitOps-Controller mit automatischer Drift-Erkennung gegen ein Git-Repository im ArgoCD/Flux-Sinne. ArgoCD und Flux sind keine Canonical-Portfolio-Produkte. Dies entspricht Score 2: GitOps als unterstütztes Drittprodukt ohne eigenes Portfolio-Produkt.

💡 Begründung: Die Anforderung verlangt explizit CAPI-Manifeste als primäres Steuerungsmittel aus dem Vendor-Portfolio. Canonical setzt auf Juju als Orchestrierungsschicht, nicht auf CAPI. Es gibt zwar experimentelle/community CAPI-Provider für MAAS, diese sind jedoch nicht als First-Party-Portfolio-Produkt etabliert. Dies entspricht Score 2: CAPI als unterstützte Konfiguration, überwiegend skriptbasiert mit CAPI-Elementen.

💡 Begründung: COS ist ein eigenes Portfolio-Produkt mit Metriken und Logs, air-gap-fähig. Tracing (OpenTelemetry) ist nicht vollständig als First-Party-Produkt integriert. IPMI/SMART-Erfassung erfordert Exporter-Konfiguration. Long-Term-Storage (Thanos o.ä.) ist nicht nativ im Portfolio. Dies entspricht Score 3: Teile des Stacks im eigenen Portfolio, Traces über Partner-Integration.

💡 Begründung: Canonical bietet CIS-Benchmarking für Ubuntu OS über Ubuntu Pro und Landscape, aber ein dediziertes, kontinuierliches CIS Kubernetes Benchmark L2 Scanning-Tool mit BSI-Grundschutz-Mapping und automatischem SIEM-Export ist nicht klar als First-Party-Produkt dokumentiert. Score 3 entspricht: CIS K8s Scanning im Portfolio, periodisch nicht kontinuierlich, Export manuell.

💡 Begründung: Es existiert kein eigenes Canonical Secrets-Management-Produkt vergleichbar mit Vault. HashiCorp Vault wird als externe Integration empfohlen. PKCS#11-HSM-Integration fehlt im eigenen Portfolio. etcd-Encryption ist manuell konfigurierbar. Dies entspricht Score 2: Secrets-Management als enge Drittprodukt-Integration, HSM eingeschränkt unterstützt.

💡 Begründung: Das Portfolio deckt OS, Provisioning, Storage, Observability, CNI (über Calico als empfohlenes CNI, aber nicht First-Party) und Registry (teilweise) ab. Für Chaos Engineering, vollständiges Secrets Management und BGP-CNI aus eigenem Portfolio bestehen Lücken. Portfolio-Abdeckung liegt bei ca. 60-70%, was Score 3 entspricht.

💡 Begründung: Canonical hat einen gut dokumentierten Patch-Prozess für Ubuntu/OS-Schicht mit USN und definierten Reaktionszeiten. Für den gesamten Stack (Ceph, Kubernetes, Juju koordiniert) ist ein formaler multi-komponentiger SLA < 72h nicht öffentlich dokumentiert. Air-Gap-Distribution ist möglich aber erfordert Konfigurationsaufwand. Score 3 passt: Patch-Prozess vorhanden, SLA < 1 Woche für kritische CVEs.

💡 Begründung: Als britisches Unternehmen (Canonical Ltd.) ist ein dediziertes KRITIS-Team mit Ü2-überprüften Ingenieuren in Deutschland nicht öffentlich nachgewiesen. Es gibt deutsche Präsenz und Partner, aber kein dediziertes KRITIS-Programm mit SÜG-konformer Personalüberprüfung ist dokumentiert. Score 2: Sicherheitsüberprüfung in Prüfung, allgemeines Enterprise-Support-Team ohne KRITIS-Spezialisierung.

💡 Begründung: Öffentliche Referenzen für Bare-Metal Kubernetes bei europäischen Energieversorgern oder TSOs in air-gapped Umgebung sind nicht bekannt oder dokumentiert. Canonical hat Telekommunikations- und Cloud-Referenzen, aber nicht nachweisbar im deutschen/europäischen Energiesektor KRITIS. Score 2: Referenzinstallation im regulierten Umfeld (nicht KRITIS) mit Kubernetes, kein Bare-Metal nachgewiesen.

💡 Begründung: Calico (als empfohlenes CNI in Charmed Kubernetes) unterstützt BGP-Peering und BFD. Die Automatisierung ist jedoch nicht vollständig end-to-end ohne manuelle Switch-Konfiguration demonstriert. Calico ist kein First-Party-Canonical-Produkt, was die Portfolio-Anforderung einschränkt. Score 3: BGP-Peering automatisierbar, BFD vorhanden, Switch-Integration erfordert manuelle Konfiguration auf Switch-Seite.

💡 Begründung: COS (Prometheus, Loki, Grafana) bietet Alerting, aber keinen strukturierten NIS-2-Meldeworkflow, keine automatische Klassifikation nach NIS-2-Kriterien und keinen STIX/TAXII- oder MISP-Export. Air-Gap ist prinzipiell möglich, aber der Meldeketten-Workflow fehlt als Portfolio-Funktion. Score 2: Grundlegendes Alerting vorhanden, Meldeketten-Integration erfordert kundenspezifische Eigenentwicklung.

💡 Begründung: Juju-Operatoren bieten automatisierte Erkennung von etcd-Ausfällen und können Remediation-Aktionen auslösen. Ein vollständig automatisierter etcd-Quorum-Recovery-Workflow ohne manuelle Intervention bei Standortausfall ist nicht als nachgewiesenes Feature dokumentiert. Learner-Node-Support hängt von der etcd-Version ab. Score 3: Automatisierte Erkennung, Recovery erfordert mehrere manuelle Schritte, dokumentierter Prozess vorhanden.

💡 Begründung: Cilium (über Charmed Kubernetes konfigurierbar) bietet eBPF-basierte L3-L7-Mikrosegmentierung mit identitätsbasiertem Ansatz, ist aber kein Canonical First-Party-Produkt. Calico ist das primäre empfohlene CNI mit L3/L4-Fähigkeiten. Vollständige mTLS/SPIFFE-basierte Identitäten erfordern zusätzliche Integration (Istio/Linkerd). Score 3: NetworkPolicies plus einfache L7-Policies vorhanden, kein vollständiger identitätsbasierter First-Party-Ansatz.

💡 Begründung: MAAS bietet native Wipe-and-Reprovision-Funktionalität mit Secure Boot und kryptografisch signierten Images. Juju-Operatoren ermöglichen deklaratives Lifecycle-Management inkl. Node-Reintegration. Die Idempotenz ist durch Juju-Operatoren strukturell gegeben. Vollständige Nachweise für <15-Minuten-Zyklus und lückenlose Automatisierung ohne jeden manuellen Schritt sind nicht öffentlich belegt, daher Score 4 statt 5.

💡 Begründung: Es gibt keine öffentlich bekannten, von Canonical erstellten BSI IT-Grundschutz-Mappings (z.B. für SYS.1.6, NET.1.1, OPS.1.1.3). Canonical fokussiert auf US-/UK-zentrierte Compliance-Frameworks (FIPS 140-2, CIS Benchmarks, DISA-STIG). Ein spezifisches Grundschutz-Profil oder -Profilierung ist nicht bekannt, weshalb Score 2 (allgemeine Compliance-Dokumentation vorhanden) angemessen ist.

💡 Begründung: Ceph bietet technisch RPO=0 bei synchroner Replikation und automatisches Failover, aber Canonical veröffentlicht keine konkreten, verifizierten RTO/RPO-Benchmarks aus Bare-Metal-Produktionsumgebungen mit dokumentiertem Latenzeinfluss auf den Schreibdurchsatz. Generelle Aussagen zu Geo-Redundanz sind vorhanden, aber keine messbaren Garantien im Sinne der Skala, daher Score 2.

💡 Begründung: Flux CD (unterstützt durch Canonical) ermöglicht Commit-Signing-Verifizierung, ist air-gap-fähig, aber das Git-Repository selbst ist ein Drittprodukt (z.B. Gitea/GitLab CE). Das 4-Augen-Prinzip ist primär prozessual über Branch-Protection realisierbar, nicht technisch auf Controller-Ebene erzwungen. Score 3: Commit-Signing möglich, aber nicht zwingend durchgesetzt, 4-Augen-Prinzip nur prozessual.

💡 Begründung: Charmed Kubernetes mit Juju bietet koordinierte, deklarative Upgrades mit Kompatibilitätsmatrizen und automatisierten Health-Checks vor Upgrades. Der automatische Rollback ohne jeglichen manuellen Eingriff über alle Schichten hinweg ist nicht vollständig belegt, insbesondere bei Storage- und CNI-Upgrades. Score 4 ist angemessen: koordiniertes Upgrade mit Matrix und Health-Checks, Rollback mit minimalem manuellem Eingriff.

💡 Begründung: MAAS und Ubuntu unterstützen Secure Boot, was Grundschutz bietet. Eine integrierte TPM 2.0 Remote Attestierung mit automatisiertem PCR-Sollwert-Management und erzwungener Cluster-Aufnahme-Verweigerung bei Abweichung ist kein bekanntes Feature des Canonical-Portfolios. Scored 2: Secure Boot vorhanden, aber keine TPM-basierte Remote Attestierung in der Provisionierungsstrecke.

💡 Begründung: MAAS bietet Hardware-Inventarisierung und IPMI/Redfish-Integration, COS bietet Dashboards. Für NVMe SMART und detaillierte NIC-Fehlerstatistiken sind node_exporter-Erweiterungen oder separate Tools erforderlich, die nicht explizit Teil des Canonical-Portfolios sind. Predictive Maintenance (ML on-prem) ist nicht bekannt. Score 3: IPMI/Redfish verfügbar, NVMe SMART und NIC erfordern Zusatz-Exporters, grundlegende Dashboards vorhanden.

💡 Begründung: Das Canonical-Portfolio umfasst kein dediziertes PAM-System mit JIT-Zugriff, zeitlich begrenzten Credentials und Session Recording. Kubernetes RBAC und Juju-Modell-Isolation bieten Basiszugangskontrolle, aber kein vollständiges PAM-Konzept. Score 1: Kein PAM-Produkt im Portfolio, permanente privilegierte Zugriffe als Standard.

💡 Begründung: Ubuntu Pro bietet FIPS 140-2/140-3 validierte Module, was eine anerkannte Sicherheitszertifizierung darstellt. Common Criteria EAL2+ oder höher für Ubuntu oder den CNI ist nicht öffentlich dokumentiert. ISO 27001 des Unternehmens ist vorhanden. Score 3: ISO 27001 vorhanden, Komponentenzertifizierungen (CC EAL) in Planung ohne konkrete Zeitlinie ist die zutreffende Kategorie.

💡 Begründung: Canonical veröffentlicht keine systematische geografische Lieferketten-Analyse oder ein kontinuierliches Monitoring-Verfahren für Drittlands-Abhängigkeiten. SBOMs werden für Ubuntu-Pakete bereitgestellt, aber ein gezieltes Drittlands-Risiko-Monitoring im Sinne der BSI-Anforderungen ist nicht dokumentiert. Score 2: Keine systematische geografische Lieferketten-Analyse, allgemeine Open-Source-Herkunft ohne spezifische Kontrollen.

💡 Begründung: Canonical betont explizit die Air-Gap-Fähigkeit aller Portfolio-Komponenten. Juju kann mit lokalem Controller arbeiten, Flux CD mit lokalem Git-Cache. Ceph-Replikation innerhalb des Standorts ist unabhängig. Ein vollständig definiertes und getestetes Wiedervereinigungsverfahren nach WAN-Wiederherstellung ohne Datenverlust ist nicht explizit dokumentiert, was Score 5 ausschließt. Score 4 ist angemessen.

💡 Begründung: Der Canonical-Stack adressiert viele Blackout-Szenarien: lokale PKI via Vault (Drittprodukt-Integration), CoreDNS für lokales DNS, Kubernetes nutzt interne TLS. NTP-Fallback auf GPS-Referenzuhr und vollständig autonomes LDAP/OIDC-Fallback aus eigenem Portfolio sind nicht bekannt. Score 3: Fallbacks für die meisten kritischen Abhängigkeiten vorhanden, einzelne Abhängigkeiten erfordern manuelle Eingriffe oder Dritttools.

💡 Begründung: Die Anforderung verlangt explizit ein Eigenprodukt mit TR-ESOR-Konformität, kryptografisch verketteten Logs (Merkle-Tree), qualifizierten Zeitstempeln nach eIDAS und WORM-Storage. Canonical hat kein solches Produkt im Portfolio. COS/Loki ist ein allgemeines Monitoring-Tool ohne Beweiswertsicherung. Score 1 gemäß Skala: kein eigenprodukt-basiertes Audit-Trail-Archivierungskonzept vorhanden.

💡 Begründung: MAAS erfüllt nahezu alle Kriterien der Score-5-Anforderung: natives Redfish- und IPMI-Support, herstellerunabhängig, vollautomatisiertes Wipe-and-Reprovision. Die CAPI-Integration erfolgt jedoch primär über den Juju/Charmed-Kubernetes-Stack und nicht über einen dedizierten Cluster-API-Provider im Sinne des upstream CAPI-Projekts, was eine vollständige Bewertung mit 5 verhindert. Mit mindestens drei BMC-Herstellern getestet, aber einzelne Sonderfunktionen können herstellerspezifische Konfiguration erfordern – Score 4 ist gerechtfertigt.

💡 Begründung: Die Anforderung verlangt CNI-seitige Unterstützung für IEC-61850-GOOSE-Multicast auf Layer 2 und latenzarmes OT-Routing als Eigenprodukt-Funktion. Canonical verwendet Calico als Standard-CNI (kein eigenes CNI-Eigenprodukt) und bietet keine dokumentierte OT-Protokoll-Referenzarchitektur. Layer-2-Multicast für GOOSE ist mit Standard-CNIs in Kubernetes grundsätzlich problematisch und erfordert externes Netzwerk-Handling. Score 2 gemäß Skala: nur Standard-NetworkPolicies ohne OT-Protokoll-Support, Layer-2-Multicast nicht nativ unterstützt.

💡 Begründung: Canonical-Kernkomponenten (MAAS, Juju, MicroK8s, Charmed Ceph) sind quelloffen unter freien Lizenzen (GPL, Apache), was grundsätzlich eine Notfall-Weiterführung ermöglicht. Formale Escrow-Verträge mit EU-Escrow-Anbietern oder Reproducible-Builds-Nachweise gemäß reproducible-builds.org-Spezifikation sind öffentlich nicht dokumentiert. Score 3 gemäß Skala: Quellcode-Zugang im Notfall grundsätzlich möglich durch Open-Source-Lizenzierung, aber kein aktiver Escrow-Vertrag und keine formal zertifizierten reproduzierbaren Builds nachgewiesen.

💡 Begründung: Ubuntu Core erfüllt das Konzept immutabler OS-Images mit atomaren Updates gut, ist aber nicht die Standard-Basis für Charmed Kubernetes (dort meist Ubuntu Server LTS). Die Lösung ist vorhanden, aber nicht durchgängig für alle Node-Typen als Default implementiert – daher Minimum erfüllt, aber nicht Best-in-Class.

💡 Begründung: MAAS ist eines der ausgereiftesten Open-Source-Tools für Bare-Metal-Provisioning am Markt. Alle genannten Anforderungen (API-Steuerung, Hardware-Inventar, IPMI/Redfish, Netzwerkkonfiguration, deklaratives Provisioning) werden vollständig abgedeckt – Best-in-Class gerechtfertigt.

💡 Begründung: Juju-Operatoren sind explizit für deklaratives Lifecycle-Management konzipiert. Upgrades, Konfigurationsänderungen und Dekommissionierung werden vollständig automatisiert und idempotent abgehandelt – dies ist eine zentrale Stärke des Produkts und erfüllt die Anforderung auf Best-in-Class-Niveau.

💡 Begründung: Juju bietet grundlegendes Multi-Cluster-Management über Modelle, aber eine integrierte, featurereiches Fleet-Management-Konsole mit Policy-Enforcement über Cluster-Grenzen hinweg ist nicht im selben Reifegrad wie spezialisierte Lösungen vorhanden. Minimum erfüllt, aber erhebliche Lücken gegenüber Best-in-Class.

💡 Begründung: FluxCD kann als Juju-Charm deployed werden und ermöglicht GitOps-Workflows. Dies ist jedoch eine Integration externer Tooling und keine native First-Class-GitOps-Funktion. Minimum ist erfüllt, aber die Integration ist nicht so tief wie bei spezialisierten Plattformen – Score 3 angemessen.

💡 Begründung: Die notwendigen Mechanismen sind verfügbar und integrierbar, jedoch nicht als native, vorkonfigurierte Kernfunktion des Stacks. Konservative Bewertung mit Score 3 da erheblicher manueller Konfigurationsaufwand erforderlich ist.

💡 Begründung: Runtime Security ist nicht Teil des Canonical Kubernetes Kernportfolios. Zwar können externe Tools wie Falco deployt werden, aber es gibt keinen eigenen Canonical-Mechanismus für verhaltensbasierte Anomalieerkennung auf Container-Ebene. Dies entspricht Score 2 – rudimentär, erhebliche Lücken.

💡 Begründung: Canonical bietet zwar ESM und Livepatch für OS-Pakete, aber kein nativ integriertes Container-Image-Scanning in der Pipeline oder Registry. Die Anforderung kann nur über externe Tools erfüllt werden, was Score 2 (rudimentär, erhebliche Lücken) rechtfertigt.

💡 Begründung: Calico und Cilium als unterstützte CNIs bieten vollständige NetworkPolicy-Unterstützung, Egress-Kontrolle und BGP-Peering. Dies übertrifft das Minimum deutlich. Score 4 statt 5 da die Integration/Konfiguration dieser CNIs als separate Charms erfolgt und nicht als vollständig vorkonfigurierter Stack ausgeliefert wird.

💡 Begründung: Geo-redundante Ceph Stretch-Cluster sind eine explizit dokumentierte und unterstützte Funktion des Canonical-Stacks. Die enge Integration zwischen Charmed Ceph und Charmed Kubernetes über Juju ist Best-in-Class für integrierte Storage-Lösungen auf Bare-Metal.

💡 Begründung: LXD als systemnaher VM/Container-Hypervisor ist eine starke Canonical-eigene Lösung für gemischte Workloads und tief in den Stack integriert. KubeVirt-Integration ist ebenfalls möglich. Score 4 statt 5 da KubeVirt-native Kubernetes-VM-Verwaltung (wie bei OpenShift Virtualization) nicht gleichwertig ausgereift ist.

💡 Begründung: Air-Gap-Betrieb ist eine explizit dokumentierte und unterstützte Kernfunktion des Canonical-Stacks. MAAS, Juju, lokale Snap-Mirrors und private Container-Registries ermöglichen vollständig disconnected Betrieb – Best-in-Class für diese Anforderung.

💡 Begründung: FIPS 140-2 ist für Ubuntu 20.04/22.04 LTS über Ubuntu Pro offiziell verfügbar und wird aktiv genutzt; die Integration in den Kubernetes-Layer ist möglich, aber nicht vollständig automatisiert out-of-the-box, was Best-in-Class (5) verhindert. Score 4 ist angemessen, da die Basis-OS-Zertifizierung vorhanden und reif ist.

💡 Begründung: CIS- und DISA-STIG-Unterstützung ist durch Ubuntu Pro und ua-client gut abgedeckt; automatisiertes Reporting und integrierte Dashboards existieren, BSI IT-Grundschutz ist jedoch nicht out-of-the-box abgebildet. Score 4 ist gerechtfertigt, da die Anforderung gut, aber nicht vollständig best-in-class erfüllt wird.

💡 Begründung: Das integrierte Registry-Addon von MicroK8s ist für einfache Szenarien geeignet, aber für HA und umfangreiches Mirroring wird typischerweise auf externe Lösungen verwiesen. Dies entspricht dem Minimum (3) gemäß Skala – ausreichend, aber mit Lücken gegenüber einer vollintegrierten HA-Registry.

💡 Begründung: COS ist ein reifer, vollständig integrierter Stack, der alle geforderten Komponenten abdeckt und über Juju-Operatoren automatisiert deployt wird. Der Score 4 (Gut, übertrifft Minimum) ist angemessen, da der Stack zwar vollständig ist, aber gegenüber Best-in-Class-Lösungen wie OpenShift Monitoring in Sachen Out-of-the-box-Vorintegration leicht aufholt.

💡 Begründung: Es gibt keine eigene CI/CD-Engine oder Image-Build-Funktionalität im Canonical-Portfolio für Kubernetes. Dies ist eine erhebliche Lücke gegenüber der Anforderung und entspricht Score 2 (rudimentär, erhebliche Lücken) – externe Lösungen sind möglich, aber nicht integriert.

💡 Begründung: Die Kombination aus Kubernetes RBAC, Juju-Modell-Isolation und Calico Network Policies ergibt eine robuste Multi-Tenancy-Lösung. Score 4 ist angemessen, da dies gut über die Mindestanforderung hinausgeht, aber hardened Multi-Tenancy-Features wie hierarchische Namespaces oder dedizierte Tenant-Operator fehlen nativ.

💡 Begründung: SLAs und Enterprise-Support sind vorhanden und ausgereift; deutschsprachiger First-Level-Support und explizite KRITIS/BSI IT-Grundschutz-Referenzen sind jedoch nicht klar belegt, was den Score auf 3 (Minimum erfüllt) begrenzt – ein britisches Unternehmen mit globalem, primär englischsprachigem Support.

💡 Begründung: Die Kombination aus MAAS (Bare-Metal-Provisioning), Charmed Ceph (verteilter Storage), LXD (VM/Container-Hypervisor) und Charmed Kubernetes ist eine der ausgereiftesten Open-Source-HCI-Stacks und deckt alle Anforderungen vollständig aus einem Portfolio ab. Score 5 ist gerechtfertigt.

💡 Begründung: NKP erfüllt die Anforderungen an vollständige und dokumentierte APIs (Kubernetes-native REST-APIs, Nutanix Prism APIs, FluxCD-Integration) und gängige Integrationen sind vorhanden. Fertige Out-of-the-box-Konnektoren zu klassischen EAI/API-Management-Systemen sind jedoch nicht explizit Teil des Produktportfolios, was einen Score von 5 verhindert. Score 4 ist angemessen.

💡 Begründung: Der vorinstallierte Prometheus/Grafana-Stack erlaubt detailliertes Monitoring von API-Endpunkten, Cluster-Komponenten und Netzwerkschnittstellen; Alertmanager ermöglicht proaktive Benachrichtigungen. Spezifisches Interface-Monitoring für externe Middleware-Verbindungen (z.B. dedizierte API-Gateway-Health-Checks) ist nicht explizit als Feature hervorgehoben, daher kein Score 5, aber die Lösung übersteigt klar das Basis-Niveau von Score 3.

💡 Begründung: NKP unterstützt benutzerdefinierte Rollen und RBAC auf Workspace/Projekt-Ebene sowie OPA-basierte Policies, was deutlich über statisches RBAC hinausgeht. Eine vollständig granulare pfadbasierte Berechtigungssteuerung wie in Score 5 beschrieben ist für eine K8s-Plattform nicht typisch; der Fokus liegt auf Namespace/Cluster-Level-Permissions, daher Score 4.

💡 Begründung: OIDC-Integration ist klar dokumentiert und ermöglicht modernes Auth sowie grundlegendes Provisioning über den IdP. SCIM-Support als natives Feature ist für NKP nicht bekannt, weshalb Score 5 nicht vergeben werden kann. Score 4 (Modern Auth & Basic Provisioning via OIDC) trifft am besten zu.

💡 Begründung: NKP (ex-Kommander/Konvoy) integriert Dex als Identity Broker, der sowohl OIDC als auch SAML-Konnektoren unterstützt und vom Kunden selbst konfiguriert werden kann, ohne Vendor-Eingriff. Dies entspricht dem Score-5-Kriterium für Self-Service OIDC & SAML.

💡 Begründung: Das Kommander-Framework bietet explizit isolierte Projekte und Workspaces mit separaten RBAC-Zuweisungen und Ressourcentrennung, was dem Score-5-Kriterium 'Full Logical Multi-Tenancy (Projects/Orgs)' entspricht.

💡 Begründung: Als Kubernetes-Plattform verwendet NKP etcd als primären Datenspeicher (embedded im K8s-Control-Plane). Für Applikations-Metadaten einiger Kommander-Komponenten sind externe DBs optional möglich, aber nicht mandatory für alle Komponenten. Konservative Einschätzung ergibt Score 3 (Optional External DB).

💡 Begründung: Nutanix Objects bietet S3-Kompatibilität als natives Backend, und NKP unterstützt S3-kompatible Endpunkte allgemein. Native Integration mit Azure Blob oder GCS ohne S3-Kompatibilitätslayer ist nicht dokumentiert, daher Score 4 (S3-Compatible Gateway Support).

💡 Begründung: Velero ermöglicht geplante Backups und Cleanups, was 'Basic Scheduled Cleanup' entspricht. Ein vollständiges Policy-basiertes Archivierungs-Framework mit Tiering (wie Score 4-5 beschreibt) ist für eine K8s-Plattform nicht der primäre Anwendungsfall. Score 3 ist angemessen.

💡 Begründung: NKP ist klar auf On-Premise/HCI ausgerichtet (Bare-Metal, Air-Gap). Kein SaaS-Angebot vom Vendor. Deployment auf Hyperscalern ist technisch möglich (CAPI-Unterstützung), aber nicht der dokumentierte Hauptanwendungsfall. Score 3 (Strong On-Premise with Basic PaaS/Container Support) trifft am besten zu.

💡 Begründung: Als HCI-/Bare-Metal-Plattform hat NKP spürbaren Hardware-Bedarf (mehrere Nodes für HA, ausreichend RAM/CPU für alle integrierten Komponenten wie Monitoring, Logging, Flow Security). Containerisierung ist nativ unterstützt, aber der Gesamtfootprint ist für Standard-Hardware spürbar ressourcenintensiv. Score 3 ist angemessen.

💡 Begründung: Der NKP-Installationsprozess nutzt CAPI und einen NKP-CLI mit strukturierten Befehlen und Skripten, was deutlich über manuelle Installation hinausgeht. Pre-Requisites wie Netzwerkkonfiguration und Hardware-Setup sind manuell erforderlich. Score 4 (Scripted Installation) ist angemessen.

💡 Begründung: Kommander als zentrale Management-Ebene mit FluxCD-GitOps, zentralem App-Katalog und clusterübergreifendem RBAC entspricht dem Score-5-Kriterium 'Full Federation with Central Repository'. Multi-Cluster über Standorte ist ein dokumentiertes Kernfeature von NKP.

💡 Begründung: Die enge Integration von NKP mit Nutanix HCI (lokaler NVMe-Storage, optimiertes Netzwerk) liefert gute Performance für Standard- und Enterprise-Szenarien. Größere Deployments mit vielen Clustern und dem vollen Observability-Stack können Tuning erfordern. Score 4 (Good performance for most enterprise scenarios with minor tuning needs) ist angemessen.

💡 Begründung: NKP bietet bewährte Skalierungsmechanismen (Node Autoscaler, Multi-Cluster), die für die meisten Enterprise-Workloads ausreichen. Für extreme Concurrency-Szenarien sind jedoch Tuning und Planung erforderlich, was einen Score von 5 verhindert. Score 4 ist angemessen.

💡 Begründung: Multi-Cluster-Management ermöglicht Deployments an verschiedenen Standorten, aber dedizierte Latenz-Mitigation (CDN, Edge-Proxy, intelligentes Caching für Remote-Nutzer) sind nicht als Stärke bekannt. Score 3 (basic mitigation, moderate effectiveness) ist konservativ aber zutreffend.

💡 Begründung: Die No-Code-Fähigkeiten decken Standard-Operations ab (Workspace-Verwaltung, App-Katalog, grundlegendes RBAC), aber tiefergehende Anpassungen erfordern YAML/Helm/OPA-Kenntnisse. Score 3 entspricht 'basic no-code for standard settings, advanced needs require coding'.

💡 Begründung: Starke API-Landschaft (K8s API, Kommander API, Flux), dokumentierte Extensibility über Helm/FluxCD und OPA. Einige Limits bei tiefer Produktintegration ohne Source-Code-Zugang verhindern Score 5. Score 4 ist angemessen.

💡 Begründung: Enterprise RBAC und externe IdP-Integration (OIDC/LDAP) sind vorhanden und ermöglichen die Governance für Offshore-Teams. Explizite Gäste-Kollaborations-Features sind weniger prominent als bei dedizierten DevOps-Plattformen, daher Score 4 statt 5.

💡 Begründung: Hauptsächlich API/GitOps-basierte Integration und Automation; kein dediziertes Plugin-Framework oder natives Webhook-System außerhalb Kubernetes-Standards. Score 3 (mostly API-based, limited native extension points) ist zutreffend.

💡 Begründung: Starke zentrale Verwaltbarkeit über Kommander-UI und API, GitOps-Konsistenz durch FluxCD. Für sehr große Multi-Tenant-Umgebungen kann Konsistenz-Enforcement komplex werden. Score 4 (strong centralized controls, good maintainability) ist angemessen.

💡 Begründung: Hybride Situation: Viele Kern-Komponenten sind OSS und einsehbar, aber der proprietäre Nutanix-Orchestrierungsanteil ist nicht open-source. Score 3 (partial source availability, constrained for full product modification) ist korrekt.

💡 Begründung: Gute Release-Kadenz und strukturierte Upgrade-Guidance sind bekannte Stärken der Nutanix-Plattform. Regressionsrisiko bei komplexen Multi-Cluster-Setups erfordert jedoch Validierungsaufwand. Score 4 (good regular release model, moderate regression effort) ist angemessen.

💡 Begründung: Starkes HA-Fundament durch Nutanix HCI plus Kubernetes-natives Backup via Velero und Multi-Cluster-DR. Kein vollautomatisches aktiv-aktiv DR out-of-the-box, was Score 5 verhindert. Score 4 ist angemessen.

💡 Begründung: Rolling-Update-Mechanismus ist CAPI-nativ vorhanden und gut dokumentiert. Für Control-Plane-Upgrades kann kurze Downtime auftreten; vollständig Zero-Downtime in allen Szenarien ist nicht garantiert. Score 4 (low-downtime upgrades feasible with recommended architecture) ist zutreffend.

💡 Begründung: Bei On-Premise-Deployments gibt es keinen Provider-seitigen Uptime-SLA für die Plattform. Nutanix bietet Support-SLAs (Reaktionszeiten), aber keine Availability-SLA für das Produkt selbst. Score 2 (limited formal SLA relevance for typical deployment model) ist korrekt.

💡 Begründung: Die Plattform kombiniert mehrere komplexe Subsysteme (Kommander, FluxCD, CAPI, Flow Security). Laut Skala entspricht dies eher Score 2 (steiler Lernkurve, häufige Anleitung notwendig), da die Zielgruppe explizit Kubernetes-Experten sind und das Produkt keine vereinfachten Workflows für weniger erfahrene Nutzer bietet.

💡 Begründung: Die Integration von ex-D2iQ-UI-Komponenten mit Nutanix-Prism-Elementen führt zu wahrnehmbaren UX-Inkonsistenzen an den Nahtstellen. Score 3 ist angemessen: generell konsistent, aber mit eingeschränkten Anpassungsoptionen und sichtbaren UI-Brüchen zwischen Subsystemen.

💡 Begründung: Laut Skala entspricht Score 2 'minimaler geführter UX, hauptsächlich manuelle Expertenoperation'. NKP setzt stark auf externe Dokumentation statt In-Produkt-Wizards, was typisch für infrastrukturfokussierte Enterprise-K8s-Plattformen dieser Art ist. Ein vollständiges Fehlen wäre Score 1, daher konservativ Score 2.

💡 Begründung: Die Plattform ist klar auf Plattform-Admins ausgerichtet, weniger auf Entwickler-Selbstservice. Score 3 ('ausreichende Passung mit etwas Reibung bei häufigen Aufgaben') trifft zu, da Admin-Workflows abgedeckt sind, Developer-Experience aber Lücken aufweist.

💡 Begründung: Die UI-Produktivitätsfunktionen sind für eine infrastrukturfokussierte K8s-Plattform begrenzt; Power-User nutzen primär die CLI. Score 2 ('eingeschränkte Produktivitätsunterstützung') ist angemessen, da keine nachgewiesenen erweiterten Keyboard-/Filterfeatures in der UI vorhanden sind.

💡 Begründung: NKP fokussiert auf organisatorische Isolation (Workspaces, Projekte) statt auf individuelle Nutzeranpassung. Score 2 ('begrenzte Personalisierungsoptionen') ist korrekt, da keine dokumentierten per-User-UX-Anpassungsfeatures bekannt sind.

💡 Begründung: Für Enterprise-K8s-Plattformen ist englischsprachige UI die Norm; NKP bietet keine bekannte Mehrsprachigkeit. Score 2 ('begrenzte Sprach-/Lokalisierungsunterstützung') ist konservativ angemessen, da rein englische UI mit minimal dokumentierten Lokalisierungsoptionen vorliegt. Score 1 wäre nur bei vollständigem Fehlen jeglicher locale-Einstellungen.

💡 Begründung: Ohne explizite Dokumentation zu WCAG-Konformität, Keyboard-Navigation oder Accessibility-Testing ist eine konservative Bewertung geboten. Score 2 ('begrenzte Unterstützung für inklusive Interaktion') spiegelt den Mangel an nachgewiesener Accessibility-Fokussierung wider; Score 1 würde vollständiges Fehlen bedeuten.

💡 Begründung: Die Anforderung zielt auf Daten-Governance und Anbindung an führende Quellsysteme per API. NKP adressiert dies nur mittelbar (GitOps, API-basiertes Management), ist aber keine MDM-Lösung. Partielle Abdeckung rechtfertigt Score 3 auf der Compliance-Skala.

💡 Begründung: Da NKP primär On-Premise läuft, liegt die Standortwahl vollständig beim Kunden (EU-Konformität möglich). Allerdings bietet Nutanix als Vendor keine eigene Cloud-Infrastruktur in bevorzugten Regionen/Hyperscalers; die Hyperscaler-Integration (Azure, AWS) ist möglich, aber nicht nativ integriert. Score 4 wegen sehr guter regionaler Kontrolle bei kleinen Einschränkungen bzgl. Hyperscaler-nativer Features.

💡 Begründung: FIPS 140-2 und TLS-Unterstützung sind dokumentierte Features. Verschlüsselung at rest und in transit ist verfügbar, aber nicht immer standardmäßig für alle Datenebenen aktiviert (z.B. storage encryption je nach Konfiguration). Score 4 gemäß Skala: gute Abdeckung mit einigen deployment-abhängigen Aspekten.

💡 Begründung: NKP ist eine Infrastrukturplattform; Nutanix als Hersteller hat grundlegende Datenschutzdokumente, aber spezifische BDSG-Nachweise, Auftragsverarbeitungsverträge und Löschkonzepte für personenbezogene Daten müssen kundenseitig implementiert werden. Score 3 wegen grundsätzlicher Möglichkeit zur Compliance, aber begrenzter herstellerseitiger Governance-Evidenz.

💡 Begründung: Nutanix als Unternehmen ist ISO 27001-zertifiziert und verfügt über ein solides Compliance-Portfolio. Da NKP teilweise aus der D2iQ-Akquisition stammt, ist die vollständige Zertifikatsabdeckung aller Komponenten konservativ als nicht lückenlos einzustufen. Score 4 gemäß Skala: ISO 27001 verfügbar, leichte Nachweislücken bei Teilkomponenten.

💡 Begründung: Kubernetes-native APIs, Velero, S3-kompatibles Storage und FluxCD bieten starke programmatische Export-/Import-Fähigkeiten. Manuelle GUI-basierte Massenoperationen (Excel-Upload etc.) sind nicht Teil des Produktumfangs, was Score 5 verhindert. Score 4 gemäß Skala: starke Export-/Import-Unterstützung mit kleinen Einschränkungen.

💡 Begründung: Die Nutzung von Nutanix Objects, Files und Flow Network Security als integrierte Backend-Dienste bindet den Kunden stark an Nutanix-Hardware und -Software. Ein Ablösen erfordert Migration aller Storage-Workloads, Netzwerkkonfigurationen und des Cluster-Managements. Trotz Open-Source-Basis der K8s-Schicht ergibt sich durch HCI-Abhängigkeiten ein 'Strong platform dependency' → Score 2.

💡 Begründung: Die Integration von D2iQ-Expertise in Nutanix-Teams ist noch nicht vollständig konsolidiert; es bestehen moderate Fluktuationsrisiken im spezialisierten NKP-Bereich. Nutanix als Unternehmen ist grundsätzlich stabil, aber die NKP-spezifische Teamkontinuität ist unsicher → Score 3 (Adequate capability with some continuity risk).

💡 Begründung: Für On-Premise/Air-Gapped Bare-Metal-Deployments ist der initiale Aufwand durch Hardware-Vorbereitung, CAPI-Konfiguration und Air-Gap-Bundle-Management erheblich. Kein Cloud-ähnliches schnelles Provisioning möglich → moderate Lead Time entspricht Score 3.

💡 Begründung: Nutanix hat Enterprise-Erfahrung, aber die kombinierte NKP-Plattform (Kubernetes + HCI + Security) erfordert seltene Cross-Domain-Skills. Großkundenprojekte mit dieser Kombination sind noch nicht zahlreich referenziert → Adequate capability → Score 3.

💡 Begründung: Nutanix ist ein etabliertes, finanziell stabiles Unternehmen mit signifikanter Marktkapitalisierung und breiter Kundenbasis. Kein relevantes Insolvenzrisiko; ausreichend groß für Großkundensupport → Score 4 (Large and credible supplier base).

💡 Begründung: Nutanix-Support ist global vorhanden, aber NKP als kombinierte Plattform ist neu und NKP-spezialisierte Ressourcen sind nicht gleichmäßig verteilt. Für weltweite Rollouts bestehen moderate Lücken in manchen Regionen → Score 3 (Moderate global reach).

💡 Begründung: Keine bekannten direkten positiven Synergien oder Konflikte mit gängigen Enterprise-Strategieprogrammen. Indirekte Abhängigkeiten könnten bei gemeinsamer HCI-Infrastruktur entstehen, sind aber managebar → neutrale Position → Score 3.

💡 Begründung: NKP unterstützt GitOps (FluxCD), CI/CD-Integration und iterative Cluster-Updates, was eine agile Projektdurchführung auf Kundenseite fördert. Nutanix selbst nutzt agile Entwicklungsmethoden mit regelmäßigen Minor-Releases → Good modern delivery fit → Score 4.

💡 Begründung: Die Skala sieht Score 2 für 'High setup cost' vor. NKP erfordert Bare-Metal-/HCI-Infrastrukturplanung, Cluster-API-Kenntnisse, Integration von Nutanix Objects/Files/Flow sowie ggf. FIPS- und Air-Gap-Vorbereitung. Das ist konzeptionell und organisatorisch aufwändig; Score 3 wäre nur gerechtfertigt, wenn die Nutanix-Umgebung bereits vorhanden und das Team erfahren ist.

💡 Begründung: Score 2 ('High implementation effort') ist angemessen: Das Produkt bündelt viele Komponenten (Storage, Networking, Security, Observability), die alle konfiguriert und integriert werden müssen. Der vorintegirerte Stack reduziert den Aufwand gegenüber einer vollständigen Eigenentwicklung, bleibt aber komplex. Score 3 wäre möglich, wenn Nutanix-Expertise bereits im Haus ist.

💡 Begründung: Score 3 ('Moderate operating effort'): Die integrierten Automatisierungstools (FluxCD, Prometheus, Velero, Cluster Autoscaling) reduzieren den manuellen Aufwand spürbar. Allerdings ist der Stack umfangreich (HCI + K8s + Networking + Storage), was spezialisiertes Personal und kontinuierliche Pflege erfordert. Kein reiner Self-Service-Cloud-Dienst, aber besser als vollständig manuell verwaltete K8s-Cluster.

💡 Begründung: Score 2 ('Teuer oder intransparent'): Nutanix-Lizenzierung ist bekannt für node-/core-basierte Bündelmodelle, bei denen NKP-Funktionen an NCI/NCM-Lizenzstufen gebunden sind. Transparenz und Vergleichbarkeit mit Wettbewerbern sind eingeschränkt; der Gesamtpreis ist signifikant und enthält variable Komponenten (Support-Tiers, Add-ons). Ohne öffentliche Preisliste ist die Kalkulation schwierig.

💡 Begründung: Score 4 ('Strong efficiency benefit'): Die Konsolidierung von HCI, K8s, Security und Storage auf einer Plattform mit zentralem Lifecycle-Management reduziert Lizenz-Sprawl, Integrationsaufwand und Betriebskosten in Folgejahren erheblich. Für Organisationen, die bereits auf Nutanix HCI setzen, ist der Hebel besonders groß. Score 5 wird nicht vergeben, da die initiale Komplexität den Effizienzgewinn etwas dämpft.

💡 Begründung: Nutanix hat ein etabliertes Partner-Support-Modell und ein eigenes Support-Portal (portal.nutanix.com) mit Hotline-Option. First-Level kann durch zertifizierte Partner übernommen werden, was dem Kunden Flexibilität gibt. Kein Score 5, da kein dediziertes White-Label-1st-Level-Modell für alle Partner-Konstellationen dokumentiert ist.

💡 Begründung: Nutanix verfügt über globale Support-Engineering-Teams, die Second-Level-Eskalationen übernehmen. Die Integration in Kundenprozesse ist über das Support-Portal und API-Schnittstellen möglich. Score 4 statt 5, da spezifische SLA-Garantien für 2nd-Level-Reaktionszeiten nicht immer transparent öffentlich dokumentiert sind.

💡 Begründung: Nutanix hat einen dokumentierten Engineering-Eskalationspfad über seinen globalen Support. Bugfixes werden über NEXT-Portal und interne Ticketing-Systeme nachverfolgt. Score 4, weil der Prozess solide ist, aber für NKP als relativ neue Plattform (D2iQ-Akquisition) die Engineering-Integration noch reifen kann.

💡 Begründung: Nutanix hat ein dokumentiertes mehrstufiges Support-Konzept mit klaren Tiers. Ticket-Bridge-Integration ist über das Nutanix Support Portal API möglich. Weltweiter Support ist vorhanden. Mehrsprachiger Support (primär Englisch, ergänzend weitere Sprachen) ist bekannt. Score 4 statt 5, da die Tiefe der Mehrsprachigkeit und die Ticket-Bridge-Dokumentation für NKP spezifisch konservativ bewertet wird.

💡 Begründung: Nutanix dokumentiert Response-Time-SLAs nach Severity-Level in seinen Support-Verträgen. Severity 1: ~1h, Severity 2: ~4h, Severity 3/4: nächster Werktag (tierspezifisch). Score 4, da die SLAs solide und dokumentiert sind, aber Lösungszeit-SLAs (nicht nur Reaktionszeit) weniger präzise definiert sind.

💡 Begründung: Nutanix betreibt globale Support-Center und bietet 24/7-Erreichbarkeit für Severity-1-Fälle als Standard in allen höheren Support-Tiers. Dies ist ein bekanntes und gut dokumentiertes Merkmal des Nutanix Enterprise-Supports. Score 5 ist gerechtfertigt.

💡 Begründung: Nutanix University ist eine etablierte Trainingsplattform mit Videos, Webinaren, Hands-on-Labs und Zertifizierungen. Für NKP gibt es spezifische Kurse. Die Dokumentation auf portal.nutanix.com ist umfangreich. Score 4 statt 5, da NKP-spezifische Kurse (post D2iQ-Akquisition) noch nicht vollständig den Reifegrad der Core-HCI-Trainings erreicht haben.

💡 Begründung: Nutanix hat kein Talos Linux- oder Flatcar-äquivalentes Eigenprodukt. Es gibt keinen dokumentierten A/B-Update-Mechanismus für ein eigenes OS-Produkt und kein SSH-freies, rein API-gesteuertes OS im Portfolio. Gemäß Skala ist Score 1 korrekt: Kein immutables OS im Portfolio.

💡 Begründung: NKP verwendet CAPI mit Bare-Metal-Provider (Tinkerbell-basiert), der aus der D2iQ-Akquisition stammt. Dies ist eine Akquisitions-Integration, kein originäres Nutanix-Eigenentwicklungsprodukt. BMC-Unterstützung ist konfigurierbar, aber der vollständige deklarative Wipe/Reprovision-Zyklus hat dokumentierte Einschränkungen. Score 3 gemäß Skala: CAPI Provider über Akquisition integriert, Teilautomatisierung.

💡 Begründung: Flow Network Security bietet Mikrosegmentierung, aber kein natives BGP-Peering zu physischen Switches ohne Overlay aus dem eigenen Portfolio. CNI-Optionen wie Calico oder Cilium werden als Drittprodukte unterstützt. Ein eigenes eBGP-fähiges, overlay-freies CNI mit eBPF-Dataplane ist nicht im Nutanix-Portfolio dokumentiert. Score 2: CNI-BGP-Unterstützung nur als Partner/Drittprodukt.

💡 Begründung: Der integrierte Prometheus/Grafana-Stack ermöglicht etcd-Monitoring mit Latenz-Metriken. NVMe-spezifische Dashboards und automatische Eskalation bei IOPS/Latenz-Schwellwertüberschreitungen sind nicht als dedizierte Portfolio-Features dokumentiert. Runbook-basiertes NVMe-Tuning ist möglich. Score 3: Generisches Monitoring mit etcd-Metriken, NVMe-Tuning über Runbooks.

💡 Begründung: NKP ist bekannt für seinen Air-Gap-Betrieb mit eigenem Bundle-Mechanismus. Nutanix Objects (S3-kompatibel) dient als lokale Registry, Helm-Charts werden lokal gespiegelt. Es gibt dokumentierte, weitgehend automatisierte Bundle-Export/Import-Prozesse. Einzelne manuelle Schritte können bei der initialen Konfiguration anfallen. Score 4 gemäß Skala: Air-Gap-Komponenten im Portfolio vorhanden, weitgehend automatisiert.

💡 Begründung: Weder aus der D2iQ-Akquisition noch aus Nutanix-Eigenentwicklung ist ein Chaos-Engineering-Produkt im NKP-Portfolio bekannt. Chaos Engineering muss durch Drittprodukte wie Chaos Mesh oder LitmusChaos ergänzt werden. Score 1: Kein Chaos-Engineering im Portfolio.

💡 Begründung: NKP bietet Multi-Cluster-Management mit FluxCD-GitOps über Standorte hinweg. Nutanix HCI unterstützt Stretched Clusters auf Storage-Ebene, aber die Kombination für Kubernetes-Multi-Site mit automatischem Fencing ist nicht als vollständige, dokumentierte Referenzarchitektur mit Split-Brain-Prevention auf allen Ebenen nachgewiesen. Score 3: Multi-Site über Kombination von Portfolio-Produkten, Risikomitigierung durch Konfigurationsempfehlungen.

💡 Begründung: Nutanix Metro Availability bietet synchrone/nahe-synchrone Replikation für HCI-Storage. Die Integration mit Kubernetes PVs über NKP ist vorhanden, aber spezifische Latenz-Overhead-Messungen (<5ms bei 50ms RTT) und automatisches Failover <30s für Kubernetes PVs sind nicht klar dokumentiert. Score 3: SDS im Portfolio, synchrone Replikation konfigurierbar, Failover teilautomatisiert.

💡 Begründung: Flow Network Security fokussiert auf Netzwerkpolicies und Mikrosegmentierung, nicht auf kernelnahes eBPF-basiertes Angriffserkennungs-/Blocking auf Syscall-Ebene. Ein Tetragon-äquivalentes Produkt ist nicht im Nutanix-Portfolio. Score 1: Kein eBPF-basiertes Angriffserkennungssystem im Portfolio.

💡 Begründung: OPA/Gatekeeper ermöglicht Policy-basiertes Blocking im Admission-Controller, aber SBOM-Erstellung/-Prüfung, Cosign-Integration und CVE-Scanning sind nicht als integrierte NKP-Portfolio-Features dokumentiert. Drittprodukte wären notwendig für eine vollständige Supply-Chain-Security-Suite. Score 2: Einzelkomponenten (Admission Controller) vorhanden, vollständige Integration fehlt.

💡 Begründung: NKP bietet Workspaces, RBAC-Isolation, OPA/Gatekeeper und Flow Network Security für Netzwerktrennung. Physische dedizierte Node-Zuweisung ist konfigurierbar. Jedoch fehlen automatisierte BSI-Compliance-Reports und eine native VLAN/VRF-bis-ToR-Integration ohne manuelle Switch-Konfiguration. Score 3: Logische Mandantentrennung aus Portfolio, physische Trennung über Konfigurationsempfehlungen.

💡 Begründung: FluxCD ist über die D2iQ-Akquisition ins NKP-Portfolio integriert und wird als eigenes Portfolio-Feature beworben. Drift-Erkennung und automatische Korrektur sind vorhanden, aber als Akquisitions-Komponente (nicht Nutanix-Eigenentwicklung). Air-Gap-Betrieb ist möglich mit Konfigurationsaufwand. Score 3: GitOps über Akquisition im Portfolio, Drift-Erkennung vorhanden, Korrektur eingeschränkt konfigurierbar.

💡 Begründung: NKP basiert nachweislich auf CAPI (aus dem ex-D2iQ-Portfolio) für Bare-Metal-Provisioning und Lifecycle-Management. Upgrades sind deklarativ über Manifest-Änderungen möglich und air-gap-fähig. Es gibt jedoch dokumentierte Ausnahmen und Konfigurationsschritte (z.B. OS-Image-Vorbereitung), die nicht vollständig skriptlos sind, was einen Score von 5 verhindert. Score 4 ist passend.

💡 Begründung: Der Stack deckt Metriken und Logs gut ab (Prometheus/Grafana/Loki via vorinstallierte Add-ons), aber Traces via OpenTelemetry sind keine native Kernkomponente des NKP-Portfolios. IPMI/SMART-Metriken erfordern externe Exporter ohne eigenes Nutanix-Produkt. Eine einheitliche Korrelations-UI über alle drei Dimensionen ist nicht als eigenes Nutanix-Produkt vorhanden. Das entspricht Skala 3: Metriken gut im Portfolio, Logs/Traces über enge Partner-Integration.

💡 Begründung: Nutanix NKP hat kein eigenes dediziertes Compliance-Scanning-Produkt für CIS K8s L2 oder BSI-Grundschutz-Mapping im Portfolio. OPA/Gatekeeper deckt Policy-Enforcement ab, ist aber kein Compliance-Scanner. Kontinuierliches CIS-Scanning mit BSI-Export ist nicht als Portfolio-Eigenprodukt nachweisbar. Skala 2 trifft zu: CIS-Scanning nur über Drittprodukt-Integration möglich.

💡 Begründung: Nutanix hat kein eigenes Secrets-Management-Produkt im Portfolio. PKCS#11-HSM-Integration, automatische Secret-Rotation und etcd-Encryption mit HSM-verwalteten Schlüsseln erfordern die Integration von Drittprodukten (Vault, etc.). Dies entspricht Skala 2: enge Drittprodukt-Integration mit eingeschränktem HSM-Support, kein First-Party-Produkt vorhanden.

💡 Begründung: Das Portfolio deckt schätzungsweise 65-75% der geforderten Kernfunktionen ab: Bare-Metal OS-Image (eigenes), CAPI (ex-D2iQ), CNI/Flow Security (eigenes), Storage (Objects/Files, eigenes), GitOps (FluxCD integriert), Observability (teilweise), Security (Flow). Schwächen bei: Secrets/HSM (kein eigenes Produkt), Chaos Engineering (kein Portfolio-Produkt), dedizierte Container Registry (kein eigenes Produkt), vollständige Trace-Observability. Score 3 passt: >70% Abdeckung mit geteilter Support-Verantwortung bei einigen Funktionen.

💡 Begründung: Nutanix hat einen etablierten CVE-Advisory-Prozess für sein HCI-Portfolio, und NKP erbt den Image-Bundle-Mechanismus für Air-Gap-Updates. Ein koordinierter Multi-Komponenten-Patch-Prozess mit belegbarem < 72h SLA für CVSS ≥ 9.0 ist in der Öffentlichkeit nicht klar dokumentiert. Score 3 ist konservativ angemessen: Patch-Prozess vorhanden, SLA < 1 Woche plausibel, air-gap konfigurierbar, aber keine dokumentierten 72h-SLAs.

💡 Begründung: Nutanix hat allgemeinen Enterprise-Support mit deutschen Ressourcen, aber kein dokumentiertes dediziertes KRITIS-Team mit Ü2-Sicherheitsüberprüfung nach SÜG. KRITIS-spezifische Referenzen im deutschen Energiesektor sind nicht öffentlich verfügbar. Dies entspricht Skala 2: allgemeines Enterprise-Support-Team ohne nachgewiesene KRITIS-Spezialisierung, Sicherheitsüberprüfung in Prüfung.

💡 Begründung: Weder Nutanix noch ex-D2iQ haben öffentlich bekannte, verifizierbare Referenzinstallationen bei europäischen Energieversorgern oder TSOs mit Bare-Metal K8s air-gapped. Nutanix hat HCI-Referenzen im regulierten Umfeld (Behörden, Healthcare), aber kein dokumentierter Energiesektor-KRITIS-Fall ist bekannt. Konservative Bewertung: Score 2 – reguliertes Umfeld ohne spezifischen KRITIS/Energiesektor-Bare-Metal-Nachweis.

💡 Begründung: Flow Network Security ist primär ein VM-/Pod-Mikrosegmentierungs-Tool innerhalb von Nutanix AHV, kein vollständiges BGP-CNI für Kubernetes mit nativer ToR-Switch-Peering-Automatisierung und BFD. BGP-Peering zu Arista/Cisco-Switches mit automatischer Pod-CIDR-Ankündigung ist kein dokumentiertes Feature aus dem NKP-Flow-Portfolio. Dies entspricht Skala 2: BGP möglicherweise konfigurierbar, aber kein natives BFD, manuelle Eingriffe auf beiden Seiten erforderlich.

💡 Begründung: Nutanix NKP hat keine dokumentierten NIS-2-spezifischen Incident-Response-Workflows, keine STIX/TAXII-Export-Funktionen und keine automatisierte Meldeketten-Unterstützung für BSI-Anforderungen im eigenen Portfolio. Grundlegendes Alerting ist vorhanden, aber die für NIS-2 erforderliche automatisierte Klassifikation und maschinenlesbare Aufbereitung fehlt. Score 2 ist angemessen.

💡 Begründung: CAPI Machine Health Checks bieten automatische Node-Erkennung und -Ersatz, was teilweise etcd-Quorum-relevante Operationen abdeckt. Vollautomatisches etcd-Member-Management bei Standortausfall (georedundant) mit Learner-Node-Promotion ist kein explizit dokumentiertes NKP-Feature. Recovery nach Standortausfall erfordert laut allgemeinem Kubernetes/CAPI-Kenntnisstand mehrere manuelle Schritte. Score 3: automatisierte Erkennung, Recovery mit mehreren manuellen Schritten, dokumentierter Prozess vorhanden.

💡 Begründung: Flow Network Security bietet nachweislich mehr als Standard-Kubernetes-NetworkPolicies: App-basierte Policies, Namespace-Isolation, eingeschränkte L7-Fähigkeiten. Jedoch fehlt ein vollständiger SPIFFE/SPIRE-basierter identitätsbasierter Ansatz mit mTLS für unveränderliche Workload-Identitäten. Für OT/IT-Konvergenz-Szenarien ist die Segmentierung funktional, aber nicht auf dem höchsten Identitäts-Sicherheitsniveau. Score 3 ist angemessen: über NetworkPolicies hinaus, aber kein vollständig identitätsbasierter Ansatz.

💡 Begründung: CAPI ermöglicht prinzipiell automatisiertes Node-Reprovisioning, aber UEFI Secure Boot mit kryptografisch verifizierten OS-Images als erzwungene Bedingung und nachweisliche Idempotenz sind für NKP nicht öffentlich dokumentiert. Die Skala verweist bei Score 2 auf 'PXE-Boot automatisierbar, kein Secure Boot, manuelle Verifikation' – das trifft am ehesten zu.

💡 Begründung: Es sind keinerlei öffentlich zugängliche oder dokumentierte BSI IT-Grundschutz-Mappings von Nutanix bekannt. Score 1 der Skala ('Kein BSI IT-Grundschutz-Mapping verfügbar') trifft zu; eine konservative Bewertung ist hier angemessen.

💡 Begründung: Nutanix kennt Metro Availability (RPO=0, synchrone Replikation) für virtualisierte Umgebungen auf AHV, aber im Kontext NKP auf Bare-Metal sind diese Garantien nicht direkt übertragbar und nicht mit Bare-Metal-Benchmarks belegt. Score 2 ('Generelle RTO/RPO-Aussagen ohne konkrete Messwerte oder Bare-Metal-Nachweis') ist konservativ aber zutreffend.

💡 Begründung: FluxCD unterstützt Commit-Signing-Verifizierung (cosign/GPG), aber das Enforcement auf Controller-Ebene sowie das 4-Augen-Prinzip sind nicht native NKP-Portfoliofunktionen, sondern Konfigurationsoptionen. Das Git-Repository selbst ist ein Drittprodukt. Score 3 ('Commit-Signing möglich, aber nicht zwingend auf Controller-Ebene durchgesetzt, 4-Augen-Prinzip nur prozessual') trifft zu.

💡 Begründung: NKP/Kommander hat eine dokumentierte Upgrade-Orchestrierung und Versionskompatibilitäts-Informationen, aber ein lückenloser automatischer Rollback-Mechanismus über alle Portfolio-Schichten ohne manuelle Eingriffe entspricht nicht dem bekannten Produktstand. Score 3 ('Upgrade-Dokumentation vorhanden, teilautomatisierte Checks, Rollback manuell aber dokumentiert') ist angemessen.

💡 Begründung: TPM 2.0 Remote Attestierung als erzwungene Bedingung für Cluster-Aufnahme ist kein dokumentiertes NKP-Feature. Score 1 ('Keine TPM-Integration oder Hardware-Root-of-Trust in der Provisionierungsstrecke') ist die korrekte Bewertung gemäß Skala.

💡 Begründung: Der Observability-Stack von NKP ist auf Kubernetes- und Applikations-Metriken ausgerichtet. Hardware-Level-Monitoring (IPMI, SMART, NIC) ist nicht im Portfolio integriert. Score 2 ('Nur Kubernetes-Metriken, Hardware-Level-Monitoring erfordert separate Drittsoftware') trifft zu.

💡 Begründung: NKP hat kein PAM-Portfolio-Produkt. Score 1 ('Kein PAM-Produkt im Portfolio, permanente privilegierte Zugriffe als Standard') ist die korrekte Einordnung gemäß Skala.

💡 Begründung: FIPS 140-2 und SOC2/ISO 27001 sind vorhanden, aber keine CC EAL-Zertifizierungen für Portfolio-Komponenten. Score 2 ('Allgemeine Compliance-Aussagen ohne formale Komponentenzertifizierungen') ist zutreffend; Score 3 würde ISO 27001 auf Unternehmensebene implizieren, was zutrifft, aber CC-Komponenten-Planung ist nicht dokumentiert – konservativ Score 2.

💡 Begründung: Kein dokumentiertes geografisches Lieferketten-Monitoring, keine öffentlichen Trust-Reports zur Drittlands-Abhängigkeit. Score 2 ('Keine systematische geografische Lieferketten-Analyse') ist angemessen; Score 1 wäre zu hart da SBOMs teilweise existieren.

💡 Begründung: Kubernetes-Control-Plane und laufende Workloads sowie FluxCD-Reconciliation aus lokalem Cache funktionieren im Inselbetrieb. Einige Kommander-Management-Funktionen sind WAN-abhängig. Score 3 ('Kubernetes-Control-Plane autonom, mehrere Management-Komponenten degradiert, manuelle Eingriffe für einige Operationen nötig') trifft am besten zu.

💡 Begründung: Es gibt keine dokumentierten eigenprodukt-basierten Fallbacks für alle kritischen externen Abhängigkeiten (NTP-Stratum-1, PKI-Rotation ohne externe CA, Identity ohne OIDC) in NKP. Score 2 ('Nur rudimentäre Fallbacks, wesentliche Abhängigkeiten wie IdP oder PKI nicht abgedeckt') ist die zutreffende Einordnung.

💡 Begründung: Die Skala verlangt für Score 1 explizit: kein eigenprodukt-basiertes Audit-Trail-Archivierungskonzept, nur flüchtige Log-Speicherung. NKP bietet zwar persistente Log-Aggregation via integriertem Stack, aber keine TR-ESOR-konforme Komponente mit kryptografischer Verkettung, qualifizierten Zeitstempeln oder WORM-Storage als Eigenprodukt. Eine BSI TR-03125-Konformität ist nicht dokumentiert und Nutanix vermarktet keine solche Lösung. Score 2 würde 'Standard-Log-Archivierung ohne kryptografische Sicherung' erfordern – dies trifft eher zu, jedoch fehlt auch eine explizite Langzeitarchivierungsstrategie, weshalb Score 1-2 angemessen ist; konservativ bleibt es bei 1, da das Portfolio keine dedizierte unveränderliche Archivkomponente als Eigenprodukt ausweist.

💡 Begründung: Metal3 (als CAPI-Provider für Bare-Metal) unterstützt Redfish und IPMI und ist in NKP integriert. Es handelt sich jedoch um ein Open-Source-Upstream-Projekt, nicht um ein Nutanix-Eigenprodukt im engeren Sinne. Die Skala vergibt Score 3 für: OOB-Management-Komponente vorhanden, aber nur mit einem BMC-Hersteller vollständig validiert, CAPI-Integration vorhanden, aber Wipe-und-Reprovision erfordert manuelle Schritte. Score 4 würde 'Eigenprodukt' mit Validierung bei zwei BMC-Herstellern erfordern. Da Nutanix die Lösung via Metal3 in NKP integriert, aber keine eigenentwickelte OOB-Komponente mit breiter Multi-Hersteller-Validierung als Nutanix-Eigenprodukt dokumentiert, ist Score 3 angemessen.

💡 Begründung: Die Skala weist Score 2 für 'Nur Standard-Kubernetes-NetworkPolicies ohne OT-Protokoll-Unterstützung; Layer-2-Multicast nicht unterstützt; OT-Protokolle müssen vollständig außerhalb des Clusters geroutet werden' aus. Flow Network Security ist primär auf IT-Workloads und Zero-Trust-Mikrosegmentierung ausgerichtet, nicht auf OT-Protokolle. Layer-2-Multicast (GOOSE) ist eine fundamentale Anforderung, die CNI-Lösungen typischerweise nicht nativ unterstützen. Score 3 würde 'grundlegende L3/L4-Isolation für OT-Protokolle möglich' erfordern – dies ist technisch gegeben, aber keine dokumentierte OT-Referenzarchitektur existiert. Da Layer-2-Multicast nicht unterstützt wird und keine OT-Validierung vorliegt, bleibt Score 2 angemessen.

💡 Begründung: Die Skala vergibt Score 2 für 'Escrow nur für einzelne Komponenten oder auf explizite Nachfrage; keine formale Reproducible-Builds-Strategie; Notfallbetrieb durch Kunden ohne Vendor-Unterstützung nicht realistisch.' Open-Source-Anteile (FluxCD, etc.) bieten eine gewisse Absicherung, aber die proprietären Kernkomponenten (Nutanix AOS, Flow, NKP-spezifische Orchestrierungsschichten) sind nicht mit Escrow oder reproduzierbaren Builds abgesichert. Score 3 würde eine vertraglich zugesicherte Escrow-Bereitschaft erfordern, die nicht öffentlich dokumentiert ist. Konservative Einschätzung: Score 2.

💡 Begründung: NKP basiert auf Konvoy/D2iQ-Erbe und nutzt Ubuntu oder ähnliche Distributions-Images für Nodes; ein echtes Immutable-OS mit atomaren Transaktionen und automatischem Rollback (wie z.B. Talos Linux oder CoreOS) ist nicht Teil des Produktangebots. Node-Upgrades erfolgen über Rolling-Updates via CAPI, nicht durch atomare OS-Transaktionen. Dies entspricht nach Skala einem rudimentären Ansatz (Score 2).

💡 Begründung: CAPI mit entsprechenden Bare-Metal-Providern (z.B. CAPM3/Metal3) ermöglicht deklarative Provisionierung, jedoch ist die Out-of-the-box-Integration für Hardware-Inventarisierung und vollständige IPMI/Redfish-Workflows bei NKP im Vergleich zu spezialisierten Lösungen (Tinkerbell, MAAS) eingeschränkt. Das Minimum wird erfüllt, Best-in-Class jedoch nicht erreicht (Score 3).

💡 Begründung: Das aus D2iQ Konvoy/Kommander stammende Lifecycle-Management ist eine anerkannte Kernstärke von NKP. Deklarative Cluster-Definitionen, Rolling Upgrades und automatisierte Provisionierung via CAPI sind gut implementiert. Es übertrifft das Minimum klar, erreicht aber nicht unbedingt Best-in-Class-Niveau im Vergleich zu Plattformen mit noch tieferer GitOps-Integration im Lifecycle (Score 4).

💡 Begründung: Kommander wurde explizit für Multi-Cluster-Management entwickelt und ist tief in NKP integriert. Policy-Enforcement, Workspace-Isolation und Fleet-Observability sind vorhanden. Leichte Abzüge, da die Reife nach der Nutanix-Akquisition und Integration noch in manchen Bereichen bewertet werden muss; dennoch klar über Mindestanforderung (Score 4).

💡 Begründung: FluxCD als integrierte GitOps-Engine ist eine dokumentierte Kernkomponente von NKP. Cluster-Konfigurationen und App-Deployments via Helm-Charts werden GitOps-nativ verwaltet. Die Integration ist gut, erreicht aber nicht unbedingt das Niveau von dedizierten GitOps-Plattformen (z.B. ArgoCD mit erweiterter UI). Score 4 ist angemessen.

💡 Begründung: OPA/Gatekeeper ist vorhanden und kann theoretisch Policies zur Image-Verifikation erzwingen, jedoch fehlt eine integrierte End-to-End-Lösung für kryptografische Image-Signierung (Sigstore, Notary v2, Cosign). Dies stellt eine erhebliche Lücke für eine vollständige Supply-Chain-Security dar. Score 2 (rudimentär) ist konservativ aber angemessen.

💡 Begründung: Laufzeit-Sicherheitsüberwachung auf Container-Ebene (Syscall-Analyse, Behavioral Detection à la Falco) ist kein ausgewiesenes Feature von NKP. Flow Network Security bietet Mikrosegmentierung, aber keine Container-Runtime-Anomalieerkennung. Dies ist eine signifikante Lücke für diese Anforderung (Score 2).

💡 Begründung: Weder eine integrierte Container-Registry mit CVE-Scanning noch ein eingebettetes Vulnerability-Scanner-Tool ist als dokumentiertes NKP-Feature bekannt. Für Air-Gapped Environments existiert ein Image-Bundle-Mechanismus, aber kein Scanning. Dies entspricht Score 2 (erhebliche Lücke).

💡 Begründung: Flow Network Security ist explizit als Kernstärke für Netzwerksegmentierung und Zero-Trust dokumentiert. Granulare Policies auf Namespace/Pod-Ebene sowie Egress-Kontrolle sind vorhanden. Abzüge für möglicherweise eingeschränkte Layer-7-Fähigkeiten (Service-Mesh-Level) und BGP-Integration, die nicht als Kernfeature ausgewiesen ist (Score 4).

💡 Begründung: Nutanix HCI unterstützt Stretch-Cluster und Geo-Replikation auf Infrastrukturebene, diese Features sind jedoch primär Nutanix AOS/HCI-Features und nicht spezifisch Kubernetes-nativ oder Teil von NKP selbst. Die Abhängigkeit von der Nutanix-Hypervisor-Schicht und fehlende cloud-native verteilte Storage-Lösung (wie Rook/Ceph nativ in K8s) limitiert den Score. Minimum wird erfüllt (Score 3).

💡 Begründung: KubeVirt oder eine vergleichbare Kubernetes-native VM-Laufzeitumgebung ist kein dokumentiertes Feature von NKP. Nutanix betreibt VMs über AHV separat von der Kubernetes-Schicht. Dies ist eine erhebliche Lücke für die Anforderung der VM-Workload-Ausführung auf Kubernetes (Score 2).

💡 Begründung: Air-Gap-Deployment mit eigenem Image-Bundle-Mechanismus ist explizit als Kernstärke des Produkts dokumentiert. Die vollständige Unterstützung für Registry, Operator-Katalog und Update-Pfade im Air-Gap-Modus entspricht Best-in-Class-Niveau (Score 5).

💡 Begründung: FIPS 140-2 Unterstützung ist als bekanntes Feature explizit dokumentiert, was klar über eine rudimentäre Implementierung hinausgeht. Da 140-3 nicht explizit erwähnt wird und die Reife/Vollständigkeit im Vergleich zu spezialisierten Government-Plattformen (z.B. OpenShift) etwas konservativer einzuschätzen ist, ergibt sich Score 4 (gut, übertrifft Mindestanforderung, aber nicht Best-in-Class).

💡 Begründung: OPA/Gatekeeper erlaubt das Durchsetzen von CIS-konformen Policies, und der Observability-Stack liefert Audit-Logs, jedoch fehlen fertige Compliance-Dashboards und automatisiertes Reporting für CIS L1/L2, DISA-STIG oder BSI IT-Grundschutz out-of-the-box. Das entspricht dem Minimum (Score 3), da grundlegende Bausteine vorhanden, aber erhebliche Eigenleistung erforderlich ist.

💡 Begründung: Der Air-Gap-Mechanismus ist eine Stärke, aber eine eigenständige integrierte HA-Registry mit Mirroring-Funktion ist nicht explizit als Feature gelistet. Dies entspricht dem Minimum (Score 3), da die Air-Gap-Anforderung grundsätzlich adressiert wird, die native HA-Registry-Komponente aber fehlt und extern bereitgestellt werden muss.

💡 Begründung: Prometheus, Grafana, Alertmanager und zentralisiertes Logging sind als bekannte Features explizit dokumentiert und multi-cluster-fähig. Dies übertrifft die Mindestanforderung deutlich, da keine manuellen Drittintegrationen nötig sind. Score 4, da die Vollständigkeit und Reife des Stacks gut ist, aber gegenüber Best-in-Class-Lösungen mit tieferer AIOps-Integration noch Raum nach oben besteht.

💡 Begründung: Eine eigene, integrierte CI/CD-Pipeline-Engine und Image-Build-Fähigkeiten sind nicht als NKP-Kernfeatures dokumentiert. FluxCD adressiert nur den CD/GitOps-Teil. Dies entspricht Score 2 (rudimentär, erhebliche Lücken), da wesentliche Teile der Anforderung (CI, Image-Build) durch externe Lösungen abgedeckt werden müssen.

💡 Begründung: Rollenbasierte Mehrmandantenfähigkeit mit Workspaces, RBAC und Namespace-Isolation ist als explizites Feature dokumentiert und durch Flow Network Security auf Netzwerkebene verstärkt. Dies übertrifft die Mindestanforderung (Score 4), da sowohl Plattform- als auch Netzwerkisolation integriert sind. Für Score 5 fehlt ggf. eine tiefere Hierarchical-Namespace-Controller-Integration oder ähnliche Enterprise-Erweiterungen.

💡 Begründung: Nutanix hat einen deutschen Vertrieb und Partner-Ecosystem sowie Standard-SLA-Modelle, aber spezifische deutschsprachige Support-Optionen, KRITIS-Referenzen oder BSI IT-Grundschutz-Nachweise für NKP sind nicht öffentlich prominent dokumentiert. Konservative Einschätzung ergibt Score 3 (ausreichend, erfüllt das Minimum als etablierter Enterprise-Anbieter mit Deutschlandpräsenz).

💡 Begründung: HCI auf Bare-Metal ist das fundamentale Differenzierungsmerkmal von Nutanix: AHV als Hypervisor, AOS als verteiltes Storage-OS, Nutanix Objects/Files als Container-Storage und NKP als K8s-Schicht sind vollständig integriert. VMs und Container auf gemeinsamer Hardware sind eine dokumentierte und ausgereifte Stärke. Dies entspricht eindeutig Score 5 (Best-in-Class).

💡 Begründung: TKG stützt sich auf offene Kubernetes-APIs (vollständig dokumentiert) sowie herstellerspezifische REST-APIs für NSX-T, Aria und TMC. Die API-Dokumentation ist vorhanden, jedoch über mehrere Produkte verteilt (nicht einheitlich). Out-of-the-box-Konnektoren für Middleware (z.B. EAI/EDI-Manager) sind begrenzt; gängige Integrationen wie vRA/Aria Automation, Terraform-Provider und Harbor-API sind vorhanden. Ein vollständiger Score 5 wird nicht erreicht, da fertige Konnektoren für Enterprise-Middleware (PI/CPI/EDI) nicht nativ integriert sind und die Fragmentierung über das Portfolio die Nutzung erschwert.

💡 Begründung: Mit Aria Operations, Aria Log Insight und NSX-T Network Detection and Response ist ein gutes bis starkes Interface-Monitoring vorhanden. Es existieren klare operative Diagnosen für Netzwerk- und API-Schnittstellen. Score 5 wird nicht vergeben, da das Monitoring über mehrere Aria-Komponenten verteilt ist und eine einheitliche, vollintegrierte Interface-Monitoring-Oberfläche fehlt; zudem ist der Konfigurationsaufwand für vollständige Abdeckung nicht trivial.

💡 Begründung: Kubernetes RBAC ermöglicht granulare Rollen-Erstellung auf Namespace-/Ressourcen-Ebene, was über rein statische Rollen hinausgeht. Allerdings fehlt ein vollständiges ABAC-System mit path-basiertem Filtering im Sinne der Skala; es entspricht eher 'Static bis Flexible RBAC' auf Kubernetes-Ebene. Score 3 ist konservativ angemessen.

💡 Begründung: Die Unterstützung erfolgt primär über SAML/LDAP und OIDC via Dex, ohne nativ implementiertes SCIM für vollständigen User-Lifecycle. Dies entspricht der Skalenebene 3 (Legacy/Basic Auth & Basic Provisioning).

💡 Begründung: Starke OIDC-Self-Service-Konfiguration möglich (Dex ermöglicht eigenständige Konfiguration), jedoch ist SAML2.0 nicht gleichwertig nativ unterstützt. Score 4 entspricht 'Self-Service for OIDC or SAML (nicht beide gleichwertig)'.

💡 Begründung: Die Kombination aus TMC, vSphere-Namespaces und NSX-T-Mikrosegmentierung ermöglicht starke Datentrennung. User-Management ist teilweise noch global (vCenter-Ebene), daher Score 4 statt 5.

💡 Begründung: Die Anforderung passt nicht zum Produktcharakter einer Kubernetes-Infrastrukturplattform. etcd als Kubernetes-State-Store ist eingebettet und kein flexibles Enterprise-DB-System. Score 1 reflektiert, dass das Produkt nicht für diesen Anwendungsfall konzipiert ist; konservative Bewertung.

💡 Begründung: Die Kernplattform ist auf vSAN/lokales Storage ausgerichtet. S3-Integration existiert nur für Backup-Szenarien via Velero. Für flexible Cloud-Object-Storage-Nutzung als primäres Backend sind Workarounds notwendig, was Score 2 rechtfertigt.

💡 Begründung: Als Kubernetes-Infrastrukturplattform fehlt eine umfassende Policy-Engine für Data Archiving. Einzelne Komponenten (Harbor) haben Basis-Cleanup-Funktionen, aber kein plattformweites automatisches Archivierungs-Framework. Score 2 (manuelle Prozesse via API/Scripts dominieren).

💡 Begründung: Das Produkt ist primär On-Premise mit starker vSphere-Abhängigkeit. Kein SaaS, keine offiziell supportete Deployment-Option auf externen Hyperscalern als PaaS. Dies entspricht Score 2 (On-Premise Only, Traditional), da auch containerisiertes Deployment auf beliebigen Plattformen nicht im Scope ist.

💡 Begründung: Der Gesamtstack ist sehr ressourcenintensiv (vSAN benötigt min. 3-4 Hosts, NSX-T eigene VMs, Aria eigene Appliances). Dies entspricht Score 2 (hoher Hardware-Bedarf, eingeschränkte Optionen für kleinere Umgebungen).

💡 Begründung: Die Installation ist strukturiert und dokumentiert, aber multi-step und komplex durch die Abhängigkeiten zu vSphere, NSX-T und vSAN. Score 3 (Manual but Well-Documented) ist angemessen; Score 4 wäre nur bei vollständig automatisierten Scripts ohne manuelle Infrastrukturvoraussetzungen erreichbar.

💡 Begründung: TMC bietet zentrale Steuerung aber kein natives aktives Replikations- oder Federation-Modell für Daten. Harbor-Replikation ist ein Teilaspekt. Dies entspricht Score 3 (Proxy-/Management-basiertes Modell ohne echte Federation mit Central Repository).

💡 Begründung: Der Stack ist Enterprise-proven mit guter Performance für typische Kubernetes-Workloads. Tuning ist für große Deployments notwendig (vSAN-Policy-Tuning, NSX-T-Sizing), aber die Grundarchitektur unterstützt Enterprise-Scale gut. Score 4 ist angemessen.

💡 Begründung: Cluster API ermöglicht automatisiertes Skalieren der Node-Pools, NSX-T und vSAN skalieren ebenfalls horizontal. Für Bare-Metal-Umgebungen ist das Scaling-Modell gut, aber komplexer als bei Public-Cloud-Managed-Services. Score 4 ist angemessen, da starke Skalierbarkeit vorhanden ist, jedoch kein vollautomatisches Cloud-natives Auto-Scaling ohne zusätzliche Konfiguration.

💡 Begründung: Harbor bietet Image-Replication für geografisch verteilte Setups, und NSX-T kann WAN-Segmentierungen unterstützen, aber native Latenz-Mitigation (CDN, Edge-Proxy) ist nicht Teil des Kernprodukts. Score 3 entspricht 'Basic mitigation options with moderate effectiveness'.

💡 Begründung: Für Standard-Operationen (RBAC, Namespace-Policies, Backup-Retention via TMC) ist No-Code-Konfiguration möglich. Tiefgehende Plattform-Anpassungen und GitOps-Workflows erfordern jedoch YAML-Kenntnisse und Scripting. Score 3 passt zur Skala: 'Basic no-code customization for standard settings'.

💡 Begründung: Kubernetes-native Extension-Modelle (Operators, CRDs, Admission Webhooks), kombiniert mit REST-APIs für alle Plattformkomponenten, ermöglichen umfangreiche kundenseitige Entwicklung. Kleine Einschränkungen bestehen bei Support-Scope für stark modifizierte Umgebungen. Score 4 ist korrekt.

💡 Begründung: Enterprise RBAC mit LDAP/AD-Integration, OIDC-Support und Namespace-basierter Isolation sind etablierte Features in TKG/TMC. Explizite 'Guest/External User'-Konzepte wie bei SaaS-Plattformen fehlen, aber operative Unterstützung für verteilte Teams ist gut. Score 4 passt.

💡 Begründung: Kubernetes-native Extension-Modelle plus proprietäre APIs aller VMware-Komponenten ergeben ein starkes Erweiterungs-Ökosystem. Limitierungen bestehen bei proprietären Komponenten (NSX-T internals, vSAN), wo tiefe Änderungen nicht möglich sind. Score 4 entspricht 'Strong extension capability via scripting/API/event hooks'.

💡 Begründung: Zentralisierte Kontrolle via TMC und Aria für die wichtigsten Governance-Dimensionen ist stark. Einschränkung: Konsistenz über heterogene Environments (CAPM3 vs. CAPV) kann zusätzlichen Aufwand erfordern. Score 4 ist angemessen für 'Strong centralized controls with good maintainability'.

💡 Begründung: Der Open-Source-Anteil ist substanziell (Kubernetes-Core, Harbor, Velero, Cluster API), aber die differenzierenden Enterprise-Features (NSX-T, vSAN, Aria) sind proprietär und nicht einsehbar. Score 3 entspricht 'Partial source availability, constrained for full product modification'.

💡 Begründung: Die Release-Transparenz ist vorhanden, aber nach der Broadcom-Übernahme sind Unsicherheiten bzgl. Lifecycle-Policies entstanden. Cluster-API-Upgrades sind prozessual gut definiert, aber in Bare-Metal-Umgebungen mit NSX-T/vSAN komplex. Score 3 reflektiert 'Acceptable release model with less predictability or higher validation effort'.

💡 Begründung: Mehrstufige HA (vSAN Storage, NSX-T Controller HA, Kubernetes Control Plane HA, Velero Backup) decken die wichtigsten Failure-Szenarien ab. Dokumentation und Best Practices für Recovery-Szenarien sind vorhanden. Score 4 entspricht 'Strong recovery mechanisms and practical HA options'.

💡 Begründung: Rolling-Upgrade-Fähigkeit via Cluster API ist ein etabliertes Feature; Worker-Nodes können unterbrechungsfrei rotiert werden. Control-Plane-Upgrades haben minimale, aber nicht null Downtime-Risiken. Score 4 passt zu 'Low-downtime upgrades are feasible with recommended architecture'.

💡 Begründung: On-Premise-Deployments haben per Definition keinen Provider-seitigen Availability-SLA; Broadcom bietet Support-Verträge, aber keine Uptime-Garantie für die betriebene Plattform. Score 2 entspricht 'Limited formal SLA relevance for typical deployment model', was für On-Premise korrekt ist.

💡 Begründung: Die Plattform ist für Enterprise-Ops-Teams ausgelegt, nicht für Self-Service-Einsteiger. Mehrere Interfaces (Tanzu CLI, kubectl, vSphere-UI, TMC-Portal, Aria) müssen kombiniert werden. Kein vereinfachter 'one-stop'-Workflow für Browse/Search/Publish/Consume. Score 2 gemäß Skala: steile Lernkurve, häufige Anleitung erforderlich.

💡 Begründung: Verschiedene UI-Frameworks und Designsprachen (Clarity Design in Teilen vs. ältere vSphere-UIs vs. Aria-Konsolen) erzeugen eine inkonsistente Nutzererfahrung. Theming- oder Personalisierungsoptionen für Unternehmen sind kaum vorhanden. Score 2: inkonsistente UX über Bereiche hinweg.

💡 Begründung: In-Produkt-Assistenten existieren punktuell (vSphere Supervisor Setup), sind aber für die Mehrzahl der komplexen TKG-Workflows nicht vorhanden. Air-Gapped-Setup, CAPM3-Konfiguration und Aria-Integration erfordern manuelle Expert-Arbeit anhand umfangreicher Docs. Score 2: minimale geführte UX, überwiegend manuelle Expertenbedienung.

💡 Begründung: Admin-Workflows sind in TMC und vSphere-UI abgebildet, Developer-Self-Service erfordert jedoch zusätzliche Konfiguration oder externe Developer-Portale. Einige häufige Aufgaben (z. B. Cluster skalieren, Netzwerk anpassen) sind über mehrere UIs verteilt. Score 3: ausreichende Passform mit Reibung bei verbreiteten Aufgaben.

💡 Begründung: Grafische Interfaces (TMC, Aria, vSphere) bieten begrenzte Keyboard-Navigation und keine nennenswerten Shortcut-Systeme. Effiziente Filterung/Suche über viele Cluster oder Ressourcen ist in der GUI schwach ausgeprägt. CLI-Nutzer erhalten mehr Kontrolle, aber das entspricht nicht dem Kriterium 'broadly available'. Score 2: begrenzter Produktivitätssupport.

💡 Begründung: Die Produkte bieten RBAC-basierte Zugriffssteuerung, aber keine substanzielle Personalisierung wie Dashboard-Layouts, Theme-Auswahl oder Verhaltenseinstellungen pro Nutzer. Dies ist typisch für Infrastructure-Management-Plattformen dieser Generation. Score 2: begrenzte Personalisierungsoptionen.

💡 Begründung: vSphere hat historisch Mehrsprachigkeit, neuere Komponenten wie TMC-Portal und Tanzu CLI sind weitgehend englischsprachig. Lokalisierung von Zeit-/Datumsformaten und Gebietsschema ist in Teilen verfügbar, aber nicht durchgängig. Score 3: grundlegende Lokalisierungsunterstützung mit Lücken.

💡 Begründung: Clarity Design System (genutzt in Teilen von Tanzu) hat grundlegende WCAG-Unterstützung, aber die komplexen Administrations-UIs (NSX Manager, Aria Operations, vSphere) sind nicht primär auf Keyboard-First oder inklusive Interaktion ausgelegt. Keine expliziten Accessibility-Commitments für alle Portale bekannt. Score 2: begrenzte Unterstützung für inklusive Interaktion.

💡 Begründung: TKG adressiert Cluster- und Infrastrukturmanagement, nicht Datengovernance. Es gibt keine eingebaute Mechanismen zur Verhinderung von Datenreplikation oder zur Anbindung führender Systeme auf Plattformebene. Anpassungen auf Applikationsebene sind zwingend erforderlich – daher Score 3 (teilweise konform, Anpassungen nötig).

💡 Begründung: Als On-Premise-Plattform liegt die Kontrolle über den Serverstandort ausschließlich beim Kunden. EU-Konformität ist damit per se sichergestellt. Die Skala bewertet breite regionale Wahlfreiheit positiv – maximale Kontrolle entspricht Score 5.

💡 Begründung: Sowohl Verschlüsselung at-rest als auch in-transit sind vorhanden und enterprise-tauglich (inkl. externer KMS-Integration). Da die Aktivierung deployment- und konfigurationsabhängig ist und nicht durchgehend per Default aktiv, entspricht dies Score 4 (gut, aber deployment-abhängige Aspekte).

💡 Begründung: On-Premise-Betrieb reduziert Drittanbieter-Risiken erheblich, jedoch fehlen strukturierte DSGVO-Konzepte und Löschnachweise auf Plattformebene. Broadcom-spezifische Compliance-Nachweise (DPA, Subauftragsverarbeiter-Listen) sind nach Übernahme kritisch zu prüfen. Score 3 (grundlegende Konformität möglich, Governance-Nachweise begrenzt).

💡 Begründung: ISO 27001 ist für VMware-Rechenzentren und Entwicklungsprozesse historisch belegt; zusätzliche Zertifizierungen (SOC 2 Type II etc.) sind vorhanden. Unsicherheit besteht hinsichtlich der Fortführung unter Broadcom-Konsolidierung, daher konservativ Score 4 statt 5.

💡 Begründung: Export/Import via APIs (kubectl, Velero, CAPI, Harbor) ist gut abgedeckt. Manuelle Massenoperationen via Excel o.ä. sind nicht native Features der Plattform. Für infrastrukturelle und applikationsbezogene Daten ist die Unterstützung stark, kleinere Einschränkungen bei fachlichen Datenobjekten bleiben – Score 4.

💡 Begründung: Die Abhängigkeit von NSX-T, vSAN und Aria Operations schafft einen sehr tiefen Stack-Lock-in. Nach der Broadcom-Übernahme ist die Lizenzstrategie zusätzlich risikobehaftet. Eine De-Integration erfordert den Austausch von Netzwerk, Storage und Monitoring gleichzeitig. Score 2 gemäß Skala: starke Plattform- und Vendor-Abhängigkeit.

💡 Begründung: Einerseits existiert ein umfangreiches Partner-Netzwerk mit erfahrenen TKG-Spezialisten; andererseits hat die Broadcom-Übernahme zu signifikanter Mitarbeiterfluktuation geführt, was die Kontinuität gefährdet. Score 3: ausreichende Kapazität, aber merkliche Kontinuitätsrisiken.

💡 Begründung: Die Komplexität des gesamten Stacks (NSX-T, vSAN, vSphere, TKG) mit notwendigen Zertifizierungen, Hardwareplanung und Lizenzverhandlungen mit Broadcom führt zu langen Vorlaufzeiten. Score 2: langer Setup- und Onboarding-Aufwand gemäß Skala.

💡 Begründung: VMware hat über Jahrzehnte Erfahrung mit Großunternehmen und KRITIS-Umgebungen gesammelt. Das globale Partner-Ökosystem bietet breite Kompetenz in Consulting, Architektur und Deployment. Score 4: starke Fähigkeiten, leicht gemindert durch Post-Acquisition-Unsicherheiten.

💡 Begründung: Broadcom als Mutterkonzern ist finanziell sehr stabil und kein Insolvenzrisiko erkennbar. Allerdings besteht das Risiko von Produktabkündigungen oder Strategieänderungen. Score 4: großer und glaubwürdiger Anbieter, aber mit strategischer Unsicherheit nach der Übernahme.

💡 Begründung: Broadcom betreibt globale Support-Strukturen und hat ein umfangreiches zertifiziertes Partner-Ökosystem in allen Regionen. TKG wird weltweit bei Großkunden eingesetzt. Score 4: gute Multi-Region-Fähigkeit, leicht gemindert durch post-Acquisition Restrukturierungen.

💡 Begründung: Als Infrastrukturplattform ist TKG weitgehend entkoppelt von Applikationsprogrammen wie S/4HANA. Die geänderte Broadcom-Lizenzstrategie kann jedoch Budget- und Strategieprogramme beeinflussen. Score 3: neutrale Abhängigkeitsposition ohne klare positive oder negative Ausrichtung.

💡 Begründung: TKG unterstützt GitOps, Cluster API und CI/CD-Pipelines, was gut zu agilen Methoden passt. Aria Automation ermöglicht policy-getriebene, automatisierte Deployments. Score 4: gute moderne Delivery-Ausrichtung, leicht eingeschränkt durch Komplexität der Gesamtplattform.

💡 Begründung: Die Komplexität des Stacks (NSX-T, vSAN, vSphere, TKG, Aria) sowie die post-Broadcom-Lizenzumstellung machen den Setup-Aufwand signifikant hoch. Skala 2 = 'High setup cost' ist angemessen, da weder sehr hohe (1) noch moderate (3) Kosten treffend wären – der Einstieg ist klar überdurchschnittlich aufwändig.

💡 Begründung: Mehrstufige Integrationspunkte (CAPM3/Ironic, NSX-T BGP, vSAN CSI, Aria), proprietäre Konfigurationskonzepte und das neue Broadcom-Subscription-Modell erhöhen den Implementierungsaufwand erheblich. Score 2 ('High implementation effort') ist konservativ aber gerechtfertigt gegenüber Score 1, da vorgefertigte Integrationen vorhanden sind.

💡 Begründung: Mehrere unabhängige Produktlinien mit eigenen Upgrade-Pfaden, Zertifizierungsanforderungen und Support-Verträgen (alle nun über Broadcom konsolidiert) treiben den operativen Aufwand. Im Vergleich zu Cloud-native Alternativen ist der Betrieb ressourcenintensiver; Score 2 ('High operating effort') ist angemessen.

💡 Begründung: Marktberichte und Kundenfeedback post-Broadcom-Akquisition dokumentieren Preissteigerungen von 200-500% für einige Kunden, Abschaffung perpetueller Lizenzen und erzwungene Bundle-Pakete. Dies entspricht klar Score 1 ('Sehr teuer / nicht kalkulierbar') der Bewertungsskala.

💡 Begründung: Effizienzgewinne durch Automatisierung und integriertes Tooling sind real, werden aber durch die post-Broadcom-Lizenzkosten und den hohen operativen Aufwand teilweise aufgezehrt. Score 3 ('Moderate benefit') ist angemessen – stärkere Effizienzgewinne (4-5) sind nur realistisch, wenn bereits massiv in den VMware-Stack investiert wurde.

💡 Begründung: Ein formaler Support-Kanal ist vorhanden (Portal, Hotline, Partner-Netzwerk), jedoch berichten viele Kunden seit der Broadcom-Übernahme von verschlechterter First-Level-Qualität und reduziertem Partner-Support. Dies entspricht einem adequaten, aber nicht starken Modell – Score 3.

💡 Begründung: Das Eskalationsmodell von L1 zu L2 ist formal definiert und funktioniert über das Broadcom Support Portal, jedoch ist die Qualität der Zusammenarbeit nach der Übernahme uneinheitlich dokumentiert. Ein 'adequate second-level support' (Score 3) ist konservativ, aber realistisch.

💡 Begründung: VMware/Broadcom hat langjährige Erfahrung im Enterprise-Support mit klar definierten Eskalationspfaden bis zum Engineering. Der Prozess ist gut dokumentiert (Knowledge Base, Patch-Prozesse, CVE-Handling). Ein 'Good engineering escalation path' (Score 4) ist gerechtfertigt, da das Engineering-Backing stark ist, aber nach Broadcom-Übernahme leichte Unsicherheiten bestehen.

💡 Begründung: Das Support-Konzept ist formal stark aufgestellt (globale Abdeckung, mehrere Tiers, mehrsprachig), jedoch hat die Broadcom-Konsolidierung den Support vereinfacht und in Teilen verschlechtert. Ticket-Bridge-Optionen sind vorhanden, aber komplex in der Umsetzung. Score 3 als konservative Bewertung angesichts der Umstrukturierungen.

💡 Begründung: Die SLA-Struktur ist gut dokumentiert und entspricht Enterprise-Standard. Severity-basierte Reaktionszeiten sind klar definiert und vertraglich absicherbar. 'Good SLA offering' (Score 4) ist angemessen, da die SLAs solide sind, aber nicht zu den Top-Angeboten des Marktes zählen.

💡 Begründung: 24/7-Abdeckung ist für höhere Support-Tiers verfügbar und durch globale Support-Standorte gestützt. Die Abdeckung ist gut, aber regionale Qualitätsunterschiede existieren, was 'Good regional coverage' (Score 4) entspricht statt dem vollen 5.

💡 Begründung: Das VMware/Broadcom Trainingsportfolio ist historisch stark mit VCP/VCAP-Zertifizierungen, VMware Learning-Plattform und umfangreicher Dokumentation. Nach der Broadcom-Übernahme wurde das Portfolio teilweise angepasst, bleibt aber insgesamt stark. 'Strong documentation and training offering' (Score 4) ist angemessen.

💡 Begründung: Photon OS ist ein eigenes VMware-Produkt, aber kein immutables OS im Sinne von Talos Linux oder Flatcar. SSH ist standardmäßig aktiv, A/B-Partitionen fehlen, SBOM ist nicht als Standard-Lieferumfang dokumentiert. Dies entspricht Skala-Punkt 2 (unterstütztes Drittprodukt-Level, eingeschränkte API-Steuerung) bis bestenfalls nicht erfüllt.

💡 Begründung: CAPM3/Ironic ist im TKG-Portfolio integriert und wird als nativ unterstützt beschrieben, stammt aber aus der OpenStack-Community (Akquisitions-/Integrations-Charakter). Deklarativer Wipe/Reprovision ist weitgehend möglich, aber die Provenienz ist nicht ein originäres VMware-Eigenprodukt. Dies entspricht Skala-Punkt 3.

💡 Begründung: NSX-T ist ein Eigenprodukt mit BGP-Unterstützung und overlay-freiem Betrieb möglich, erfüllt aber die eBPF-Dataplane-Anforderung nicht. KRITIS-spezifische Referenzen für reinen Bare-Metal-eBGP-Betrieb ohne Overlay sind nicht öffentlich nachgewiesen. Skala-Punkt 3 trifft am besten zu: CNI im Portfolio, BGP vorhanden, partiell overlay-frei, kein eBPF.

💡 Begründung: Aria Operations kann etcd-Metriken über Prometheus-Integration einsammeln und Alerts konfigurieren, bietet aber kein dediziertes etcd-NVMe-Performance-Monitoring-Produkt mit automatischer Eskalation. Dies entspricht Skala-Punkt 3: generisches Monitoring mit etcd-Metriken, NVMe-Tuning über Runbooks.

💡 Begründung: Harbor ist im Portfolio, imgpkg ermöglicht Bundle-Export/Import, Helm-Charts können offline gespiegelt werden. OS-Image-Store ist über Photon-basierte OVAs abgedeckt. Vereinzelte manuelle Schritte und Konfigurationsaufwand sind dokumentiert. Dies entspricht Skala-Punkt 4.

💡 Begründung: Weder TKG noch Aria oder andere Broadcom-Produkte umfassen ein Chaos-Engineering-Tool als Eigenprodukt. Chaos Engineering-Szenarien müssen mit Drittprodukten wie Chaos Mesh realisiert werden. Skala-Punkt 1 ist korrekt.

💡 Begründung: vSAN Stretched Cluster ist ein etabliertes VMware-Produkt mit Quorum-Witness für Split-Brain-Prevention, Multi-Site-Referenzarchitekturen sind dokumentiert. KRITIS-spezifische Referenzkunden sind nicht öffentlich nachweisbar. Skala-Punkt 4 trifft zu: Multi-Site im Portfolio, Split-Brain-Prevention implementiert, keine KRITIS-spezifische Referenz.

💡 Begründung: vSAN ist ein originäres VMware-Eigenprodukt mit synchroner Geo-Replikation und automatischem Failover. Latenz-Overhead unter 5 ms bei 50 ms RTT ist nicht explizit als produktiv gemessener Wert in der Dokumentation verankert, und vereinzelte manuelle Schritte beim Failover sind möglich. Skala-Punkt 4 ist angemessen.

💡 Begründung: Carbon Black kann in TKG integriert werden und bietet Detect- und Enforce-Fähigkeiten, ist aber kein eBPF-natives Produkt im eigentlichen Sinne. BSI-Zertifizierung oder KRITIS-Referenz ist nicht dokumentiert. Skala-Punkt 2: Monitoring als unterstütztes Produkt, eingeschränkte eBPF-Tiefe.

💡 Begründung: SBOM und Signaturprüfung sind teilweise im Portfolio (Harbor), Scanner-Integration vorhanden, aber der Admission Controller stammt aus Open-Source-Projekten ohne Broadcom-Eigenentwicklung. Air-Gap-CVE-Feed ist eingeschränkt. Skala-Punkt 3: Teile der Supply-Chain-Security im Portfolio, Lücken durch Drittprodukte.

💡 Begründung: Physische Node-Isolation, VLAN/VRF-Trennung via NSX-T und RBAC-Isolation sind im Portfolio abgedeckt. Compliance-Reporting via Aria ist vorhanden. KRITIS-spezifische Referenzkunden sind nicht öffentlich belegt, und automatisierte BSI-Compliance-Reports sind nicht als dediziertes Feature dokumentiert. Skala-Punkt 4 ist zutreffend.

💡 Begründung: Aria Automation deckt GitOps-Aspekte für Infrastruktur-Lifecycle ab, aber ein dedizierter GitOps-Controller für Kubernetes-Drift-Erkennung und -Korrektur mit < 5 min Erkennung als Eigenprodukt ist nicht klar nachgewiesen. Flux-Integration ist vorhanden aber kein Eigenprodukt. Skala-Punkt 3: GitOps über Portfolio-Integration, Drift-Erkennung eingeschränkt, air-gap möglich.

💡 Begründung: TKG basiert nativ auf Cluster API mit CAPM3/Ironic-Integration; deklarativer Lifecycle ist das Kernkonzept. Rollback-Fähigkeit und air-gap sind möglich, jedoch erfordert die initiale air-gap-Einrichtung manuelle Konfigurationsschritte. Score 5 würde 'vollständig demonstrierbar ohne jede Ausnahme' erfordern; vereinzelte dokumentierte Ausnahmen rechtfertigen Score 4.

💡 Begründung: Aria Operations bietet Metriken und Logs aus eigenem Portfolio, jedoch fehlt eine native OpenTelemetry-Traces-Lösung als Eigenprodukt. IPMI/SMART nur über externe Exporter. Das entspricht Score 3 ('Teile des Stacks im eigenen Portfolio, Logs und Traces über enge Partner-Integration') – Traces sind nicht durch ein VMware/Broadcom-Eigenprodukt abgedeckt.

💡 Begründung: CIS K8s Scanning ist im Portfolio über Aria Operations/TMC vorhanden, jedoch ist ein dediziertes kontinuierliches BSI-Grundschutz-Mapping nicht als verifiziertes Feature nachweisbar. SIEM-Integration ist konfigurierbar aber nicht vollautomatisch. Score 3 ('periodisch, nicht kontinuierlich, Export manuell') trifft am besten zu; Score 4 würde automatisches Reporting und BSI-Export als klar dokumentiertes Feature erfordern.

💡 Begründung: VMware/Broadcom besitzt kein eigenes Secrets-Management-Produkt (kein Vault-Äquivalent im Portfolio). etcd-Encryption ist über KMS-Plugin möglich, aber HSM-Integration erfordert externe Produkte. Score 2 ('enge Drittprodukt-Integration, HSM eingeschränkt unterstützt') ist angemessen; Score 3 würde ein eigenes Portfolio-Produkt erfordern.

💡 Begründung: Mehr als 70% der geforderten Kernfunktionen sind durch VMware/Broadcom-eigene Produkte abdeckbar; Chaos Engineering ist kein VMware-Eigenprodukt, Bare-Metal-OS (CAPM3/Ironic ist Upstream CNCF, nicht VMware-eigen) und Secrets-Management erfordern Drittprodukte. Score 3 ('Portfolio > 70%, einige Funktionen über Partner-Integration') passt; Score 4 würde maximal 1-2 Lücken erlauben.

💡 Begründung: VMware/Broadcom hat etablierte Security-Advisory-Prozesse (VMSA), jedoch sind komponenten-übergreifende SLAs < 72h nicht explizit veröffentlicht. Air-gap-Distribution erfordert manuelle Schritte. Nach Broadcom-Übernahme hat sich der Support-Prozess verändert, was Unsicherheit erzeugt. Score 3 ('SLA < 1 Woche für kritische CVEs') ist konservativ aber realistisch; Score 4 würde klar dokumentierten 72h-SLA erfordern.

💡 Begründung: Broadcom ist ein US-amerikanisches Unternehmen; dedizierte KRITIS-Teams mit Ü2-Überprüfung nach deutschem SÜG sind für US-Konzerne ungewöhnlich und nicht öffentlich nachgewiesen. Score 2 ('Sicherheitsüberprüfung in Prüfung, allgemeines Enterprise-Support-Team') ist realistisch; Score 3 würde nachweisbare KRITIS-Erfahrung im Team erfordern, die nach Broadcom-Restrukturierung fraglich ist.

💡 Begründung: VMware ist traditionell VM-zentriert; Bare-Metal-Kubernetes via CAPM3/Ironic ist in TKG erst seit neueren Versionen verfügbar. KRITIS/Energiesektor-Referenzen für reines Bare-Metal K8s air-gapped sind nicht öffentlich dokumentiert. Score 2 ('reguliertes Umfeld, kein Bare-Metal') ist konservativ aber angemessen; Score 3 würde zumindest eine Energieversorger-Referenz mit VM-basiertem K8s erfordern, die plausibel aber nicht verifizierbar ist.

💡 Begründung: NSX-T unterstützt BGP und BFD nativ, jedoch erfordert die Integration mit physischen ToR-Switches typischerweise initiale manuelle Konfiguration auf Switch-Seite. Konfigurationsvorlagen für Switch-Betriebssysteme sind nicht als Standard-Portfolio-Feature dokumentiert. Score 3 ('BGP-Peering automatisierbar, BFD vorhanden, Switch-Integration erfordert manuelle Schritte auf Switch-Seite') trifft zu.

💡 Begründung: Carbon Black kann Sicherheitsereignisse klassifizieren, jedoch ist STIX/TAXII oder MISP-Export sowie ein automatisierter NIS-2-Meldeworkflow nicht als Eigenprodukt-Feature nachweisbar. Grundlegendes Alerting ist vorhanden, aber die Meldeketten-Integration erfordert kundenspezifische Eigenentwicklung. Score 2 ('grundlegendes Alerting, Meldeketten-Integration erfordert Eigenentwicklung') ist angemessen.

💡 Begründung: Cluster API Machine Health Checks erkennen Node-Ausfälle automatisch, jedoch ist etcd-Member-Management bei Standortausfall ein komplexes Szenario das in TKG nicht explizit als vollautomatischer Prozess dokumentiert ist. Recovery erfordert typischerweise mehrere manuelle Operator-Schritte. Score 3 ('automatisierte Erkennung, Recovery erfordert mehrere manuelle Schritte, dokumentierter Prozess vorhanden') ist realistisch.

💡 Begründung: NSX-T Distributed Firewall mit Policy Groups und NSX Intelligence bietet L3-L7-Segmentierung inkl. identitätsbasierter Konzepte (Tags, App-ID). L3 ist jedoch teilweise noch IP-basiert ergänzt durch Identity Firewall. GitOps-Integration ist über Aria Automation möglich. Score 4 ('identitätsbasierte Segmentierung auf L4/L7, L3 noch IP-basiert, GitOps-Integration vorhanden') trifft zu; Score 5 würde vollständige SPIFFE/mTLS-Integration als Eigenprodukt erfordern.

💡 Begründung: CAPM3/Ironic ermöglicht automatisiertes Wipe und PXE-Boot, Secure Boot ist in der UEFI-Kette unterstützt, jedoch sind mehrere manuelle Schritte bei der Cluster-Reintegration in der Praxis bekannt. Ein vollständig idempotenter, dokumentierter Zyklus unter 15 Minuten mit kryptografisch verifizierten Artefakten aus eigenem Portfolio ist nicht nachweislich belegt, was Score 3 entspricht.

💡 Begründung: Es existiert kein öffentlich bekanntes, dediziertes BSI IT-Grundschutz-Mapping-Dokument für TKG/Tanzu. Broadcom/VMware verfügt über generische Compliance-Dokumentation, aber kein spezifisches Grundschutz-Profil, was Score 2 (allgemeine Compliance-Dokumentation, kein spezifisches BSI-Mapping) entspricht.