Organizzazione e persone
Politica di sicurezza, ruoli, abilitazioni e formazione del personale. OpenKeel fornisce ruoli nominativi e la traccia di audit delle loro azioni.
OpenKeel: la soluzione Cloud sovrana, francese e di portata europea, del gruppo inherent Scopri inherent
Architettura
OpenKeel è progettato per essere SecNumCloud-ready: ciò che è conforme oggi, ciò che è in corso e ciò che resta da far evolvere, requisito per requisito, ciascuno con la sua evidenza nel codice.
SecNumCloud (ANSSI, framework 3.2) qualifica un servizio gestito da un fornitore, non un software. Il framework copre l'organizzazione, le risorse umane, la sicurezza fisica, le operazioni, la gestione degli incidenti e la protezione dal diritto extraeuropeo (§ 19.6) quanto la tecnica.
OpenKeel non può quindi essere «qualificato SecNumCloud». Punta a essere una base SecNumCloud-ready: un software che non blocca alcun requisito tecnico del framework, fornisce i meccanismi attesi (tracciabilità, segregazione, cifratura, autenticazione forte) e la documentazione che consente al fornitore di dimostrare la conformità durante l'audit.
Conteggiato dalle tabelle seguenti; la parte del fornitore è indicata a parte.
Una PKI interna gestita da cert-manager (emittente openkeel-ca) firma i certificati dei servizi; la CA dell'operatore MariaDB firma quelli del database. Ogni servizio verifica il server con cui parla.
| Flusso | Protocollo | Fiducia |
|---|---|---|
| Client → Ingress → API | HTTPS, ricifrato verso backend HTTPS (Skyline, console Nova, wsproxy di Zun) | Certificato pubblico; certificati interni cert-manager |
| API ↔ API | REST su HTTPS, URL interni https nel catalogo | PKI interna, emittente cert-manager openkeel-ca |
| Servizi → MariaDB | SQL su TLS, richiesto dal server | CA dell'operatore MariaDB, verificata da ogni servizio |
| Servizi → RabbitMQ | AMQPS (RPC e notifiche) | PKI interna openkeel-ca |
| Neutron → OVN NB/SB | OVSDB su ssl:, TLS mutuo | Certificati client e server di OVN |
Niente più Memcached né Redis: nessun componente li leggeva, e okadm li rimuove dalle installazioni esistenti. Solo le porte di amministrazione :9090 (salute, metriche), la distribuzione Erlang tra i nodi RabbitMQ e il gateway RGW di --ceph-s3 trasportano ancora traffico in chiaro nel cluster. L'intera tabella è nel codice (global.tls.internal, attivo per impostazione predefinita) ed è stata verificata nel laboratorio il 2026-11-08.
Ogni immagine eseguita da un cluster di produzione proviene dal registry del fornitore: quelle di OpenKeel, costruite dal workspace, e quelle di terzi, copiate lì con il loro SBOM. Entrambe sono firmate con la chiave del fornitore.
| Immagini | Registry | SBOM e provenienza | Firma |
|---|---|---|---|
Servizi OpenKeel, okadm, sito web | Costruite da make release e caricate in REGISTRY; i chart vi puntano (global.imageRegistry) | SBOM SPDX per piattaforma e provenienza SLSA, allegati da BuildKit nell'indice dell'immagine; esportati da make sbom | cosign, per digest dell'indice (make sign), attestazioni comprese |
Binari okadm | File di rilascio in dist/cli, con SHA256SUMS | SBOM SPDX per binario (syft) | Checksum |
| Prerequisiti: cert-manager, operatori MariaDB e RabbitMQ, MariaDB, RabbitMQ, Traefik | Copiate da registry a registry da make mirror-prereqs, tutte le piattaforme, un prefisso per registry di origine | Lo SBOM dell'editore quando la copia lo conserva, altrimenti uno SBOM syft allegato con cosign attest (MIRROR_SBOM=1) | Ogni copia firmata con la chiave OpenKeel |
| Ironic (immagini Kolla upstream) | Fissate per digest nel manifesto di versione di okadm, scaricate tramite global.imageRegistry | Tramite il mirror (MIRROR_EXTRA_IMAGES) | Tramite il mirror |
Il cluster scarica dal mirror senza modificare alcun chart: un hosts.toml per registry di origine per containerd, machine.registries.mirrors sotto Talos. Nessuna firma, SBOM o digest di immagine viene inviato ai servizi pubblici di Sigstore (build/cosign/signing-config-private.json). Fonte: BUILD.md.
Fatto nel codice e nei chart, oppure documentato per il fornitore.
| Requisito | SecNumCloud 3.2 | Stato | Evidenza | Prossimo passo |
|---|---|---|---|---|
| Controllo del codice, nessuna dipendenza da un fornitore non europeo | § 19 | Fatto | Riscrittura open source in Go di Keystone, Nova, Neutron, Cinder, Glance, Manila, Barbican… (openkeel-*); nessuna telemetria, nessuna chiamata in uscita verso terzi | Ricostruire le immagini in una CI europea |
| Registrazione delle azioni API | cap. 12 | Fatto | Un evento CADF per chiamata su ogni API (internal/audit), eventi di identità di Keystone (internal/notify), contatori openkeel_audit_events_{sent,dropped,failed}_total | Aggiungere kube-apiserver e l'API di Talos alla traccia di audit |
| Conservazione e integrità dei log | cap. 12 | Fatto | Documentato in openkeel-chart/docs/audit-trail.md: archivio WORM (object lock, modalità compliance), 12 mesi di cui 3 online (Loki 400 d), NTP sui nodi Talos, alert sulle perdite, regole SIEM | Dimostrarlo su una piattaforma reale (fornitore) |
| Controllo degli accessi alle API | cap. 9 | Fatto | Policy RBAC di OpenStack (admin, member, reader, service, scope di progetto e di sistema) applicate da ogni servizio; rifiuti 403 come in OpenStack, coperti dai test di conformità | Ridurre gli account di servizio con privilegi eccessivi |
| Gestione dei segreti e delle chiavi | cap. 10 | Fatto | Barbican in Go con un HSM PKCS#11 (internal/crypto/p11.go, test con SoftHSM) o Vault / OpenBao; rotazione della KEK (internal/manage/rotate.go) | HSM qualificato ANSSI in produzione |
| Isolamento dei container dei tenant | cap. 13 | Fatto | Zun sotto Kata Containers per impostazione predefinita (RuntimeClass kata): un kernel per container di tenant | — |
| Cifratura del control plane di rete | cap. 10, 13 | Fatto | OVN Northbound / Southbound in TLS reciproco (ssl:) tra Neutron, ovn-octavia-provider, FWaaS, VPNaaS, ovn-bgp-agent e OVN central | — |
| Le API opzionali possono essere disattivate | cap. 13 | Fatto | ec2-api può essere disattivato nel Configurator (componente ec2-api del suo catalogo) | — |
| Autenticazione a più fattori | cap. 9 | Fatto | Keystone: metodo TOTP (internal/keystone/totp.go) e regole MFA per utente (options.multi_factor_auth_rules, internal/api/mfa_test.go) | Federazione OIDC |
| Cifratura dei flussi verso il database | cap. 10 | Fatto | MariaDB con TLS obbligatorio (infrastructure.mariadb.tls.required: true), la CA dell'operatore MariaDB verificata da ogni servizio (global.tls.trustedCAs, passato da okadm a ogni release), tls=skip-verify rifiutato; applicato e verificato nel laboratorio (require_secure_transport su ON) | Verificare la replica Galera in TLS su un cluster a tre nodi (il laboratorio ne ha uno solo) |
| Suite TLS dei listener | cap. 10 | Fatto | internal/tlsx in tutti i 16 servizi (una copia di quello di Keystone): TLS 1.2 come minimo, solo ECDHE con AES-GCM o ChaCha20 (guida TLS dell'ANSSI), certificato riletto al rinnovo; RabbitMQ limitato a TLS 1.2/1.3 e alle suite AEAD | — |
| Superficie di attacco ridotta: nessun servizio dati inutilizzato | cap. 13 | Fatto | Memcached e Redis rimossi: nessun componente li leggeva; okadm li rimuove dalle installazioni esistenti (internal/deploy/retired.go) | — |
| Cifratura di ogni flusso interno | cap. 10 | Fatto | global.tls.internal: true per impostazione predefinita: CA interna cert-manager (openkeel-ca), un certificato per chart (ECDSA P-256, 90 giorni); RabbitMQ solo in AMQPS; URL interni e catalogo interno in https://; Ingress verso backend HTTPS verificati (Traefik ServersTransport, annotazioni nginx); passo okadm rabbitmq-trust; rapporti di stato di ovn-octavia-provider verso un punto di ascolto TLS dedicato di Neutron (openkeel-neutron-lbaas:9878, fuori dalla porta di amministrazione). Verificato nel laboratorio il 2026-11-08: 18 punti di ascolto in HTTPS con certificato verificato, HTTP in chiaro rifiutato, connessioni AMQP in TLS 1.3 | Cattura di rete: nessun flusso applicativo in chiaro al di fuori di :9090 |
| Integrità e tracciabilità delle immagini OpenKeel | cap. 14 | Fatto | Ogni immagine costruita con --sbom=true --provenance=mode=max (ATTEST=1, predefinito): un SBOM SPDX per piattaforma (pacchetti Debian della base distroless, ogni modulo Go) e la provenienza SLSA nell'indice dell'immagine; make sbom li esporta in dist/sbom, con lo SBOM di ogni binario okadm; make sign firma ogni indice per digest con cosign, il che copre le sue attestazioni (build/sbom.sh, BUILD.md) | Imporre le firme all'ammissione |
| Immagini di terzi su un registry controllato, con uno SBOM | cap. 14 | Fatto | make mirror-prereqs copia le immagini dei prerequisiti (cert-manager, operatori MariaDB e RabbitMQ, MariaDB, RabbitMQ, Traefik: 14 immagini) da registry a registry, tutte le piattaforme, secondo il manifesto di versione di okadm; containerd o Talos reindirizzano ogni registry di origine al mirror; MIRROR_SBOM=1 esporta uno SBOM per copia, ne allega uno con cosign attest dove l'editore non lo fornisce e firma ogni copia con la chiave OpenKeel; le immagini OpenKeel e quelle di Ironic, fissate per digest, sono scaricate tramite global.imageRegistry | Replicare le immagini che KubeVirt e CDI determinano a runtime |
I numeri di capitolo orientano la lettura; vanno verificati rispetto al framework pubblicato prima di costruire la matrice di conformità. Fonte: openkeel-docs/SECNUMCLOUD-STATUS.md.
| Requisito | SecNumCloud 3.2 | Stato | Evidenza | Prossimo passo |
|---|---|---|---|---|
| Suite TLS uniformi | cap. 10 | In corso | Servizi (tlsx) e RabbitMQ allineati; resta il lato pubblico dei controller di Ingress | Profilo TLS ANSSI sui punti di ingresso pubblici dell'Ingress |
| Chart coerenti | — | In corso | Conflitto di nomi dell'helper svc.volumes tra sub-chart (montaggio delle CA attendibili) | Prefissare gli helper per chart |
| Immagini costruite e controllate dal fornitore | cap. 14 | In corso | make release costruisce ogni immagine multi-architettura dal workspace (distroless senza root, UID 65532, senza shell) con il suo SBOM, la sua provenienza e la sua firma; la configurazione di firma predefinita non usa alcuno dei servizi pubblici di Sigstore (build/cosign/); Ironic usa ancora le immagini Kolla (Python) upstream, replicate per digest | Eseguire make release in una CI europea; sostituire le immagini Kolla |
| Sorveglianza delle vulnerabilità delle immagini | cap. 14 | In corso | make vuln (govulncheck, go mod verify) su ogni modulo Go; gli SBOM delle immagini OpenKeel e di terzi si analizzano senza riscaricare le immagini (grype, trivy sbom) | Analizzare gli SBOM a ogni rilascio e periodicamente per le nuove CVE |
| Requisito | SecNumCloud 3.2 | Stato | Evidenza | Prossimo passo |
|---|---|---|---|---|
| MFA degli amministratori tramite un IdP | cap. 9 | Da fare | Solo TOTP locale | Federazione OIDC in Keystone (IdP europeo, MFA gestita dall'IdP), mappata sui ruoli |
| MFA per gli amministratori Kubernetes | cap. 9 | Da fare | Accesso tramite kubeconfig con un certificato client (okadm access) | OIDC e MFA sul kube-apiserver, ruoli Kubernetes nominativi, nessun cluster-admin permanente |
| Configurator autenticato | cap. 9 | Da fare | UI senza login; la sua ClusterRole modifica i nodi e legge tutti i log (deploy/kustomize/base/rbac.yaml) | Autenticazione OIDC, una ClusterRole più ridotta, accesso solo dal SI di amministrazione |
| Account di servizio minimi | cap. 9 | Da fare | Ruolo admin per ec2-api (all_tenants), Masakari, Zun (binding:host_id), Skyline e neutron-vpnaas; openstack-exporter con la password di admin | Ruoli dedicati e regole di policy mirate per servizio; un exporter in sola lettura (reader di sistema) |
| Requisito | SecNumCloud 3.2 | Stato | Evidenza | Prossimo passo |
|---|---|---|---|---|
| Una chiave per tenant per i volumi | cap. 10 | Da fare | Cinder registra la chiave fissa 00000000-0000-0000-0000-000000000000 e lascia la cifratura alla StorageClass | Collegare Cinder a Barbican: una chiave per volume cifrato, nel progetto del tenant |
| Cifratura dei dischi | cap. 10 | Da fare | — | Longhorn LUKS per volume; cifratura di MariaDB, Glance e Swift |
| Cancellazione a fine contratto | cap. 19 | Da fare | — | Crypto-shredding: distruggere le chiavi Barbican del progetto, con una procedura tracciata |
| Nessun algoritmo obsoleto | cap. 10 | Da fare | Firme EC2 v0/v1 in HMAC-SHA1 accettate da Keystone (internal/keystone/ec2sign.go) | Un'opzione per accettare solo v2 (SHA-256) e v4, con le vecchie disattivate per impostazione predefinita in produzione |
| HSM qualificato | cap. 10 | Da fare | PKCS#11 generico testato con SoftHSM | Validare con un HSM qualificato ANSSI |
| Requisito | SecNumCloud 3.2 | Stato | Evidenza | Prossimo passo |
|---|---|---|---|---|
| Firme imposte all'ammissione | cap. 14 | Da fare | Immagini firmate e attestate, ma il cluster esegue qualsiasi immagine | Kyverno verifyImages o il policy-controller di Sigstore con cosign.pub, per le immagini di OpenKeel come per quelle degli operatori |
| Requisito | SecNumCloud 3.2 | Stato | Evidenza | Prossimo passo |
|---|---|---|---|---|
| SI di amministrazione separato | cap. 9, 13; PA-022 | Da fare | Una proposta scritta: zone Z1, Z2 e Z3 (openkeel-docs/SECNUMCLOUD-ADMIN-SI.md) | Rete di amministrazione, bastion, postazioni di amministrazione (fornitore) |
| Control plane separato dal data plane | cap. 13 | Da fare | Un solo cluster Talos ospita le API e i workload dei tenant | Fase 1: irrobustimento del cluster unico, agenti Nova e Zun centralizzati (nessun DSN sugli hypervisor); obiettivo: cluster di controllo e di dati separati |
| Registrazione dell'amministrazione della piattaforma | cap. 12 | Da fare | Solo le API OpenStack sono tracciate | Policy di audit del kube-apiserver, log dell'API di Talos, del bastion e dei BMC, archiviati come la traccia CADF |
| Porte di amministrazione cifrate | cap. 10 | Da fare | Salute e metriche su :9090 in HTTP in chiaro, dentro il cluster; i rapporti di stato di ovn-octavia-provider non passano più di lì: Neutron li riceve su un punto di ascolto TLS dedicato | TLS (o mTLS di Prometheus) su :9090, oppure una NetworkPolicy che lasci entrare solo Prometheus |
| Nessun supporto remoto extraeuropeo | § 19.6 | Da fare | Supporto remoto degli storage array (Pure1, accesso remoto del vendor) non disattivato da OpenKeel | Documentare e verificare che sia disattivata nella guida di installazione di produzione |
| Distribuzione Erlang di RabbitMQ | cap. 10 | Da fare | Traffico tra i nodi RabbitMQ (porta 25672) non cifrato, dentro il cluster | TLS per la distribuzione Erlang (ssl_dist), che l'operatore non gestisce |
Gateway RGW (--ceph-s3) | cap. 10 | Da fare | RGW raggiunge Keystone in HTTPS verificato (caBundleRef), ma serve S3 e Swift in HTTP in chiaro sulla porta 80 nel cluster | Porta sicura di RGW con un certificato della CA interna |
| Chiamate di okadm alle API | cap. 10 | Da fare | Tramite il proxy dei servizi dell'API server di Kubernetes in https:: cifrato, senza verificare i certificati dei pod | Chiamare tramite l'Ingress, o verificare lato client |
Le API di OpenKeel fanno parte del servizio venduto ai tenant: non sono il SI di amministrazione. La proposta separa quindi tre zone, e le interfacce di amministrazione di Z2 e Z3 (kube-apiserver, API di Talos, BMC, etcd, porte di amministrazione) sono raggiungibili solo da Z1.
| Zona | Contenuto | Chi accede |
|---|---|---|
| Z1, SI di amministrazione | Postazioni di amministrazione, bastion, IdP degli amministratori (MFA), runner di okadm e repository Git dei values, Configurator, raccolta e archiviazione dei log (Loki, SIEM, bucket WORM), mirror firmato del registry | Solo gli amministratori, dalle loro postazioni |
| Z2, control plane del servizio | API di OpenKeel, conductor, scheduler, MariaDB, RabbitMQ, Barbican, Ingress pubblico | Tenant (API pubbliche tramite l'Ingress); amministratori tramite Z1 |
| Z3, data plane | Hypervisor (KubeVirt), nodi Zun (Kata), storage (Longhorn), gateway di rete (OVN gateway, BGP) | Tenant (le loro VM e i loro container); amministratori tramite Z1 |
Raccomandazione della proposta: una rete di amministrazione e un cluster unico irrobustito fin da ora, in ogni deployment di produzione; agenti Nova e Zun centralizzati come primo sviluppo; cluster di controllo e di dati separati come obiettivo per un'offerta qualificata. Nulla di ciò è ancora implementato.
Completare TLS su ogni flusso interno, poi verificarlo con una cattura di rete.
OIDC e MFA per gli amministratori, cifratura a riposo con una chiave per tenant.
Immagini costruite in una CI europea, firme imposte all'ammissione, il SI di amministrazione e la separazione dei piani.
La matrice dei requisiti, una revisione interna, poi un pre-audit da parte di un auditor qualificato.
La maggior parte del framework riguarda il fornitore che gestisce il servizio. OpenKeel non lo sostituisce, ma non deve ostacolarlo, e fornisce parte delle evidenze.
Politica di sicurezza, ruoli, abilitazioni e formazione del personale. OpenKeel fornisce ruoli nominativi e la traccia di audit delle loro azioni.
Data center, controllo degli accessi alle sale e all'hardware. OpenKeel gira sui server del fornitore stesso, in Francia e in Europa.
Change, backup, gestione delle vulnerabilità e della capacità. okadm pianifica, installa e aggiorna un componente alla volta; Grafana mostra lo stato di ogni servizio.
Rilevamento, gestione e notifica degli incidenti. La traccia CADF, Loki e gli alert di Prometheus forniscono i fatti.
§ 19.6: proprietà, localizzazione dei dati e supporto nell'Unione europea. OpenKeel è open source, senza telemetria e senza chiamate in uscita.
Configurazioni, policy e log raccolti nella matrice di conformità, versionati con il codice.
| Passo | Cosa | Esito |
|---|---|---|
| Matrice dei requisiti | SecNumCloud 3.2 capitolo per capitolo: responsabile (OpenKeel o fornitore), meccanismo, prova | Matrice di conformità versionata con il codice |
| Revisione interna | Ogni prova verificata su un'installazione in modalità produzione | Rapporto di revisione, lacune aperte tracciate |
| Pre-audit | Auditor qualificato, su una piattaforma pilota completa | Rapporto di pre-audit e piano di trattamento |
| Penetration test PASSI | API pubbliche, evasione da VM e da Kata verso il piano di controllo, SI di amministrazione | Rapporto, correzioni e nuovo test |
| CSPN (facoltativa) | Componenti critici: Keystone, Barbican, isolamento di Kata e KubeVirt | Certificazione di primo livello dei componenti scelti |