Organisation und Personal
Sicherheitsrichtlinie, Rollen, Freigaben und Schulung des Personals. OpenKeel stellt benannte Rollen und den Audit-Trail ihrer Aktionen bereit.
OpenKeel: die souveräne französische Cloud-Lösung mit europäischer Reichweite der inherent-Gruppe inherent entdecken
Architektur
OpenKeel ist darauf ausgelegt, SecNumCloud-ready zu sein: was heute konform ist, was in Arbeit ist und was noch weiterzuentwickeln ist, Anforderung für Anforderung, jeweils mit seinem Nachweis im Code.
SecNumCloud (ANSSI, Rahmenwerk 3.2) qualifiziert einen Dienst, der von einem Anbieter betrieben wird, keine Software. Das Rahmenwerk umfasst Organisation, Personalwesen, physische Sicherheit, Betrieb, Management von Sicherheitsvorfällen und den Schutz vor außereuropäischem Recht (§ 19.6) ebenso wie die Technik.
OpenKeel kann daher nicht „SecNumCloud-qualifiziert“ sein. Es will eine SecNumCloud-ready-Grundlage sein: eine Software, die keine technische Anforderung des Rahmenwerks blockiert, die erwarteten Mechanismen bereitstellt (Rückverfolgbarkeit, Trennung, Verschlüsselung, starke Authentifizierung) sowie die Dokumentation, mit der der Anbieter die Konformität im Audit nachweisen kann.
Aus den Tabellen unten gezählt; der Anteil des Anbieters wird gesondert aufgeführt.
Eine interne PKI, betrieben von cert-manager (Issuer openkeel-ca), signiert die Zertifikate der Dienste; die CA des MariaDB-Operators signiert die der Datenbank. Jeder Dienst prüft den Server, mit dem er spricht.
| Datenfluss | Protokoll | Vertrauen |
|---|---|---|
| Clients → Ingress → APIs | HTTPS, neu verschlüsselt zu HTTPS-Backends (Skyline, Nova-Konsole, Zun wsproxy) | Öffentliches Zertifikat; interne cert-manager-Zertifikate |
| API ↔ API | REST über HTTPS, interne https-URLs im Katalog | Interne PKI, cert-manager-Issuer openkeel-ca |
| Dienste → MariaDB | SQL über TLS, vom Server verlangt | CA des MariaDB-Operators, von jedem Dienst geprüft |
| Dienste → RabbitMQ | AMQPS (RPC und Benachrichtigungen) | Interne PKI openkeel-ca |
| Neutron → OVN NB/SB | OVSDB über ssl:, gegenseitiges TLS | OVN-Client- und Serverzertifikate |
Kein Memcached und kein Redis mehr: keine Komponente las sie, und okadm entfernt sie aus bestehenden Installationen. Nur die Admin-Ports :9090 (Health, Metriken), die Erlang-Distribution zwischen den RabbitMQ-Knoten und das RGW-Gateway von --ceph-s3 übertragen im Cluster noch Klartext. Die ganze Tabelle ist im Code umgesetzt (global.tls.internal, standardmäßig aktiv) und wurde am 2026-11-08 im Lab geprüft.
Jedes Image, das ein Produktionscluster ausführt, stammt aus der Registry des Anbieters: die von OpenKeel, aus dem Workspace gebaut, und die von Drittanbietern, mit ihrem SBOM dorthin kopiert. Beide sind mit dem Schlüssel des Anbieters signiert.
| Images | Registry | SBOM und Provenienz | Signatur |
|---|---|---|---|
OpenKeel-Dienste, okadm, Website | Von make release gebaut und nach REGISTRY gepusht; die Charts verweisen darauf (global.imageRegistry) | SPDX-SBOM pro Plattform und SLSA-Provenienz, von BuildKit im Image-Index angehängt; exportiert durch make sbom | cosign, per Digest des Index (make sign), einschließlich der Attestierungen |
okadm-Binärprogramme | Release-Dateien in dist/cli, mit SHA256SUMS | SPDX-SBOM pro Binärprogramm (syft) | Prüfsummen |
| Voraussetzungen: cert-manager, MariaDB- und RabbitMQ-Operatoren, MariaDB, RabbitMQ, Traefik | Von Registry zu Registry kopiert durch make mirror-prereqs, alle Plattformen, ein Präfix pro Upstream-Registry | Das SBOM des Herausgebers, wenn die Kopie es behält, sonst ein syft-SBOM, angehängt mit cosign attest (MIRROR_SBOM=1) | Jede Kopie mit dem OpenKeel-Schlüssel signiert |
| Ironic (Upstream-Kolla-Images) | Per Digest im Release-Manifest von okadm fixiert, über global.imageRegistry bezogen | Über den Mirror (MIRROR_EXTRA_IMAGES) | Über den Mirror |
Der Cluster bezieht aus dem Mirror, ohne ein Chart zu ändern: eine hosts.toml pro Upstream-Registry für containerd, machine.registries.mirrors unter Talos. Keine Signatur, kein SBOM und kein Image-Digest wird an die öffentlichen Sigstore-Dienste gesendet (build/cosign/signing-config-private.json). Quelle: BUILD.md.
Im Code und in den Charts erledigt oder für den Anbieter dokumentiert.
| Anforderung | SecNumCloud 3.2 | Status | Nachweis | Nächster Schritt |
|---|---|---|---|---|
| Kontrolle über den Code, keine Abhängigkeit von einem außereuropäischen Hersteller | § 19 | Erledigt | Open-Source-Neuschreibung von Keystone, Nova, Neutron, Cinder, Glance, Manila, Barbican… in Go (openkeel-*); keine Telemetrie, keine ausgehenden Aufrufe an Dritte | Die Images in einer europäischen CI neu bauen |
| Protokollierung der API-Aktionen | Kap. 12 | Erledigt | Ein CADF-Ereignis pro Aufruf auf jeder API (internal/audit), Identitätsereignisse von Keystone (internal/notify), Zähler openkeel_audit_events_{sent,dropped,failed}_total | kube-apiserver und die Talos-API in den Audit-Trail aufnehmen |
| Aufbewahrung und Integrität der Logs | Kap. 12 | Erledigt | Dokumentiert in openkeel-chart/docs/audit-trail.md: WORM-Archiv (Object Lock, Compliance-Modus), 12 Monate, davon 3 online (Loki 400 d), NTP auf den Talos-Knoten, Alarme bei Verlusten, SIEM-Regeln | Auf einer realen Plattform nachweisen (Anbieter) |
| Zugriffskontrolle der APIs | Kap. 9 | Erledigt | OpenStack-RBAC-Richtlinien (admin, member, reader, service, Projekt- und System-Scopes), von jedem Dienst durchgesetzt; 403-Ablehnungen wie in OpenStack, abgedeckt durch die Konformitätstests | Überprivilegierte Dienstkonten beschneiden |
| Verwaltung von Secrets und Schlüsseln | Kap. 10 | Erledigt | Barbican in Go mit einem PKCS#11-HSM (internal/crypto/p11.go, SoftHSM-Tests) oder Vault / OpenBao; KEK-Rotation (internal/manage/rotate.go) | ANSSI-qualifiziertes HSM in der Produktion |
| Isolation der Mandanten-Container | Kap. 13 | Erledigt | Zun standardmäßig unter Kata Containers (RuntimeClass kata): ein Kernel pro Mandanten-Container | — |
| Verschlüsselung der Netzwerk-Control-Plane | Kap. 10, 13 | Erledigt | OVN Northbound / Southbound in mutual TLS (ssl:) zwischen Neutron, ovn-octavia-provider, FWaaS, VPNaaS, ovn-bgp-agent und OVN central | — |
| Optionale APIs lassen sich deaktivieren | Kap. 13 | Erledigt | ec2-api lässt sich im Configurator deaktivieren (Komponente ec2-api seines Katalogs) | — |
| Multi-Faktor-Authentifizierung | Kap. 9 | Erledigt | Keystone: TOTP-Methode (internal/keystone/totp.go) und MFA-Regeln pro Benutzer (options.multi_factor_auth_rules, internal/api/mfa_test.go) | OIDC-Föderation |
| Verschlüsselung der Datenbankflüsse | Kap. 10 | Erledigt | MariaDB mit verpflichtendem TLS (infrastructure.mariadb.tls.required: true), die CA des MariaDB-Operators von jedem Dienst geprüft (global.tls.trustedCAs, von okadm an jedes Release übergeben), tls=skip-verify abgelehnt; im Lab angewendet und geprüft (require_secure_transport auf ON) | Galera-Replikation in TLS auf einem Cluster mit drei Knoten prüfen (das Lab hat nur einen) |
| TLS-Suites der Listener | Kap. 10 | Erledigt | internal/tlsx in allen 16 Diensten (eine Kopie dessen von Keystone): mindestens TLS 1.2, nur ECDHE mit AES-GCM oder ChaCha20 (TLS-Leitfaden der ANSSI), Zertifikat bei Erneuerung neu gelesen; RabbitMQ auf TLS 1.2/1.3 und AEAD-Suiten begrenzt | — |
| Kleinere Angriffsfläche: kein ungenutzter Datendienst | Kap. 13 | Erledigt | Memcached und Redis entfernt: Keine Komponente las sie; okadm entfernt sie aus bestehenden Installationen (internal/deploy/retired.go) | — |
| Verschlüsselung jedes internen Datenflusses | Kap. 10 | Erledigt | global.tls.internal: true standardmäßig: interne cert-manager-CA (openkeel-ca), ein Zertifikat pro Chart (ECDSA P-256, 90 Tage); RabbitMQ nur über AMQPS; interne URLs und interner Katalog in https://; Ingress zu geprüften HTTPS-Backends (Traefik ServersTransport, nginx-Annotationen); okadm-Schritt rabbitmq-trust; Statusmeldungen von ovn-octavia-provider an einen eigenen TLS-Listener von Neutron (openkeel-neutron-lbaas:9878, nicht der Admin-Port). Im Lab am 2026-11-08 geprüft: 18 Listener in HTTPS mit geprüftem Zertifikat, Klartext-HTTP abgelehnt, AMQP-Verbindungen in TLS 1.3 | Netzwerkmitschnitt: kein Anwendungsverkehr im Klartext außerhalb von :9090 |
| Integrität und Rückverfolgbarkeit der OpenKeel-Images | Kap. 14 | Erledigt | Jedes Image wird mit --sbom=true --provenance=mode=max gebaut (ATTEST=1, Standard): ein SPDX-SBOM pro Plattform (Debian-Pakete der Distroless-Basis, jedes Go-Modul) und die SLSA-Provenienz im Image-Index; make sbom exportiert sie nach dist/sbom, mit dem SBOM jedes okadm-Binärprogramms; make sign signiert jeden Index per Digest mit cosign, was seine Attestierungen abdeckt (build/sbom.sh, BUILD.md) | Signaturen bei der Zulassung erzwingen |
| Drittanbieter-Images in einer kontrollierten Registry, mit SBOM | Kap. 14 | Erledigt | make mirror-prereqs kopiert die Images der Voraussetzungen (cert-manager, MariaDB- und RabbitMQ-Operatoren, MariaDB, RabbitMQ, Traefik: 14 Images) von Registry zu Registry, alle Plattformen, gemäß dem Release-Manifest von okadm; containerd oder Talos leiten jede Upstream-Registry auf den Mirror um; MIRROR_SBOM=1 exportiert ein SBOM pro Kopie, hängt mit cosign attest eines an, wo der Herausgeber keines liefert, und signiert jede Kopie mit dem OpenKeel-Schlüssel; die OpenKeel-Images und die per Digest fixierten Ironic-Images werden über global.imageRegistry bezogen | Die Images spiegeln, die KubeVirt und CDI zur Laufzeit ableiten |
Die Kapitelnummern dienen der Orientierung; sie sind vor dem Aufbau der Konformitätsmatrix mit dem veröffentlichten Rahmenwerk abzugleichen. Quelle: openkeel-docs/SECNUMCLOUD-STATUS.md.
| Anforderung | SecNumCloud 3.2 | Status | Nachweis | Nächster Schritt |
|---|---|---|---|---|
| Einheitliche TLS-Suites | Kap. 10 | In Arbeit | Dienste (tlsx) und RabbitMQ angeglichen; offen bleibt die öffentliche Seite der Ingress-Controller | ANSSI-TLS-Profil an den öffentlichen Eingangspunkten des Ingress |
| Konsistente Charts | — | In Arbeit | Namenskonflikt des Helpers svc.volumes zwischen Sub-Charts (Einbinden der vertrauenswürdigen CAs) | Die Helper pro Chart mit einem Präfix versehen |
| Vom Anbieter erstellte und kontrollierte Images | Kap. 14 | In Arbeit | make release baut jedes Image für mehrere Architekturen aus dem Workspace (Distroless ohne Root, UID 65532, ohne Shell) mit SBOM, Provenienz und Signatur; die Standard-Signaturkonfiguration nutzt keinen der öffentlichen Sigstore-Dienste (build/cosign/); Ironic läuft noch mit Upstream-Kolla-Images (Python), per Digest gespiegelt | make release in einer europäischen CI ausführen; die Kolla-Images ersetzen |
| Überwachung der Schwachstellen der Images | Kap. 14 | In Arbeit | make vuln (govulncheck, go mod verify) in jedem Go-Modul; die SBOMs der OpenKeel- und Drittanbieter-Images lassen sich prüfen, ohne die Images erneut zu beziehen (grype, trivy sbom) | Die SBOMs bei jedem Release und regelmäßig auf neue CVEs prüfen |
| Anforderung | SecNumCloud 3.2 | Status | Nachweis | Nächster Schritt |
|---|---|---|---|---|
| MFA für Administratoren über einen IdP | Kap. 9 | Offen | Nur lokales TOTP | OIDC-Föderation in Keystone (europäischer IdP, MFA durch den IdP), auf Rollen abgebildet |
| MFA für Kubernetes-Administratoren | Kap. 9 | Offen | Zugriff per kubeconfig mit Client-Zertifikat (okadm access) | OIDC und MFA am kube-apiserver, benannte Kubernetes-Rollen, kein dauerhaftes cluster-admin |
| Authentifizierter Configurator | Kap. 9 | Offen | UI ohne Anmeldung; ihre ClusterRole patcht Knoten und liest alle Logs (deploy/kustomize/base/rbac.yaml) | OIDC-Authentifizierung, eine kleinere ClusterRole, Zugriff nur aus der Administrations-IT |
| Minimale Dienstkonten | Kap. 9 | Offen | admin-Rolle für ec2-api (all_tenants), Masakari, Zun (binding:host_id), Skyline und neutron-vpnaas; openstack-exporter mit dem Admin-Passwort | Dedizierte Rollen und gezielte Richtlinienregeln pro Dienst; ein schreibgeschützter Exporter (System-reader) |
| Anforderung | SecNumCloud 3.2 | Status | Nachweis | Nächster Schritt |
|---|---|---|---|---|
| Ein Schlüssel pro Mandant für Volumes | Kap. 10 | Offen | Cinder speichert den festen Schlüssel 00000000-0000-0000-0000-000000000000 und überlässt die Verschlüsselung der StorageClass | Cinder mit Barbican verbinden: ein Schlüssel pro verschlüsseltem Volume, im Projekt des Mandanten |
| Festplattenverschlüsselung | Kap. 10 | Offen | — | Longhorn LUKS pro Volume; Verschlüsselung von MariaDB, Glance und Swift |
| Löschung am Vertragsende | Kap. 19 | Offen | — | Kryptografisches Löschen: die Barbican-Schlüssel des Projekts vernichten, mit einem nachvollziehbaren Verfahren |
| Kein veralteter Algorithmus | Kap. 10 | Offen | EC2-Signaturen v0/v1 in HMAC-SHA1 werden von Keystone akzeptiert (internal/keystone/ec2sign.go) | Eine Option, nur v2 (SHA-256) und v4 zu akzeptieren, die alten in der Produktion standardmäßig deaktiviert |
| Qualifiziertes HSM | Kap. 10 | Offen | Generisches PKCS#11, getestet mit SoftHSM | Mit einem ANSSI-qualifizierten HSM validieren |
| Anforderung | SecNumCloud 3.2 | Status | Nachweis | Nächster Schritt |
|---|---|---|---|---|
| Bei der Zulassung erzwungene Signaturen | Kap. 14 | Offen | Images signiert und attestiert, aber der Cluster führt jedes Image aus | Kyverno verifyImages oder der Sigstore policy-controller mit cosign.pub, für die Images von OpenKeel wie für die der Operatoren |
| Anforderung | SecNumCloud 3.2 | Status | Nachweis | Nächster Schritt |
|---|---|---|---|---|
| Getrennte Administrations-IT | Kap. 9, 13; PA-022 | Offen | Ein schriftlicher Vorschlag: Zonen Z1, Z2 und Z3 (openkeel-docs/SECNUMCLOUD-ADMIN-SI.md) | Administrationsnetz, Bastion, Administrationsarbeitsplätze (Anbieter) |
| Control Plane von der Data Plane getrennt | Kap. 13 | Offen | Ein Talos-Cluster trägt die APIs und die Workloads der Mandanten | Schritt 1: Härtung des einzelnen Clusters, zentralisierte Nova- und Zun-Agenten (kein DSN auf den Hypervisoren); Ziel: getrennte Control- und Data-Cluster |
| Protokollierung der Plattformadministration | Kap. 12 | Offen | Nur die OpenStack-APIs werden protokolliert | Audit-Richtlinie des kube-apiserver, Logs der Talos-API, der Bastion und der BMCs, archiviert wie der CADF-Trail |
| Verschlüsselte Admin-Ports | Kap. 10 | Offen | Health und Metriken auf :9090 im Klartext-HTTP, innerhalb des Clusters; die Statusmeldungen von ovn-octavia-provider laufen dort nicht mehr: Neutron empfängt sie auf einem eigenen TLS-Listener | TLS (oder Prometheus-mTLS) auf :9090 oder eine NetworkPolicy, die nur Prometheus zulässt |
| Kein außereuropäischer Fernsupport | § 19.6 | Offen | Fernsupport der Speichersysteme (Pure1, Fernzugriff des Herstellers) wird von OpenKeel nicht deaktiviert | Im Installationsleitfaden für die Produktion dokumentieren und prüfen, dass sie deaktiviert ist |
| Erlang-Distribution von RabbitMQ | Kap. 10 | Offen | Verkehr zwischen den RabbitMQ-Knoten (Port 25672) unverschlüsselt, innerhalb des Clusters | TLS für die Erlang-Distribution (ssl_dist), die der Operator nicht verwaltet |
RGW-Gateway (--ceph-s3) | Kap. 10 | Offen | RGW erreicht Keystone über geprüftes HTTPS (caBundleRef), liefert S3 und Swift im Cluster aber über Klartext-HTTP auf Port 80 | Sicherer Port von RGW mit einem Zertifikat der internen CA |
| Aufrufe von okadm an die APIs | Kap. 10 | Offen | Über den Service-Proxy des Kubernetes-API-Servers in https:: verschlüsselt, die Zertifikate der Pods nicht geprüft | Über den Ingress aufrufen oder clientseitig prüfen |
Die OpenKeel-APIs sind Teil des an die Mandanten verkauften Dienstes: Sie sind nicht die Administrations-IT. Der Vorschlag trennt daher drei Zonen, und die Administrationsschnittstellen von Z2 und Z3 (kube-apiserver, Talos-API, BMC, etcd, Admin-Ports) sind nur aus Z1 erreichbar.
| Zone | Inhalt | Wer Zugang hat |
|---|---|---|
| Z1, Administrations-IT | Administrationsarbeitsplätze, Bastion, IdP der Administratoren (MFA), okadm-Runner und Git-Repository der Values, Configurator, Erfassung und Speicherung der Logs (Loki, SIEM, WORM-Bucket), signierter Registry-Mirror | Nur Administratoren, von ihren Arbeitsplätzen aus |
| Z2, Control Plane des Dienstes | OpenKeel-APIs, Conductors, Scheduler, MariaDB, RabbitMQ, Barbican, öffentlicher Ingress | Mandanten (öffentliche APIs über den Ingress); Administratoren über Z1 |
| Z3, Data Plane | Hypervisoren (KubeVirt), Zun-Knoten (Kata), Speicher (Longhorn), Netzwerk-Gateways (OVN-Gateway, BGP) | Mandanten (ihre VMs und Container); Administratoren über Z1 |
Empfehlung des Vorschlags: ein Administrationsnetz und ein gehärteter einzelner Cluster ab sofort, in jedem Produktions-Deployment; zentralisierte Nova- und Zun-Agenten als erste Entwicklung; getrennte Control- und Data-Cluster als Ziel für ein qualifiziertes Angebot. Nichts davon ist bisher umgesetzt.
TLS auf jedem internen Datenfluss fertigstellen und dann mit einem Netzwerkmitschnitt prüfen.
OIDC und MFA für Administratoren, Verschlüsselung ruhender Daten mit einem Schlüssel pro Mandant.
Images in einer europäischen CI gebaut, Signaturen bei der Zulassung erzwungen, das Administrations-IS und die Trennung der Ebenen.
Die Anforderungsmatrix, eine interne Prüfung, dann ein Vor-Audit durch einen qualifizierten Auditor.
Der Großteil des Rahmenwerks betrifft den Anbieter, der den Dienst betreibt. OpenKeel ersetzt ihn nicht, darf ihm aber nicht im Weg stehen und liefert einen Teil der Nachweise.
Sicherheitsrichtlinie, Rollen, Freigaben und Schulung des Personals. OpenKeel stellt benannte Rollen und den Audit-Trail ihrer Aktionen bereit.
Rechenzentren, Zugangskontrolle zu den Räumen und zur Hardware. OpenKeel läuft auf den eigenen Servern des Anbieters, in Frankreich und in Europa.
Changes, Backups, Schwachstellen- und Kapazitätsmanagement. okadm plant, installiert und aktualisiert eine Komponente nach der anderen; Grafana zeigt den Zustand jedes Dienstes.
Erkennung, Behandlung und Meldung von Sicherheitsvorfällen. Der CADF-Trail, Loki und die Prometheus-Alarme liefern die Fakten.
§ 19.6: Eigentum, Speicherort der Daten und Support in der Europäischen Union. OpenKeel ist Open Source, ohne Telemetrie und ohne ausgehende Aufrufe.
Konfigurationen, Richtlinien und Logs, gesammelt in der Konformitätsmatrix und mit dem Code versioniert.
| Schritt | Was | Ergebnis |
|---|---|---|
| Anforderungsmatrix | SecNumCloud 3.2 Kapitel für Kapitel: Verantwortlicher (OpenKeel oder Anbieter), Mechanismus, Nachweis | Konformitätsmatrix, mit dem Code versioniert |
| Interne Prüfung | Jeder Nachweis auf einer Installation im Produktionsmodus geprüft | Prüfbericht, offene Lücken verfolgt |
| Vor-Audit | Qualifizierter Auditor, auf einer vollständigen Pilotplattform | Vor-Audit-Bericht und Maßnahmenplan |
| PASSI-Penetrationstest | Öffentliche APIs, Ausbruch aus VM und Kata in die Steuerungsebene, Administrations-IS | Bericht, Korrekturen und Nachtest |
| CSPN (optional) | Kritische Komponenten: Keystone, Barbican, Isolation von Kata und KubeVirt | Zertifizierung erster Stufe der gewählten Komponenten |