Organisation et personnel
Politique de sécurité, rôles, habilitations et formation du personnel. OpenKeel fournit des rôles nominatifs et la piste d'audit de leurs actions.
OpenKeel : la solution Cloud souveraine, française à portée européenne du groupe inherent Découvrir inherent
Architecture
OpenKeel est conçu pour être SecNumCloud-ready : ce qui est conforme aujourd'hui, ce qui est en cours et ce qu'il reste à faire évoluer, exigence par exigence, chacun avec sa preuve dans le code.
SecNumCloud (ANSSI, référentiel 3.2) qualifie un service opéré par un prestataire, pas un logiciel. Le référentiel couvre l'organisation, les ressources humaines, la sécurité physique, l'exploitation, la gestion des incidents et la protection vis-à-vis des droits extra-européens (§ 19.6) autant que la technique.
OpenKeel ne peut donc pas être « qualifié SecNumCloud ». Il vise à être un socle SecNumCloud-ready : un logiciel qui ne fait obstacle à aucune exigence technique du référentiel, qui fournit les mécanismes attendus (traçabilité, cloisonnement, chiffrement, authentification forte) et la documentation qui permet au prestataire de démontrer sa conformité pendant l'audit.
Compté à partir des tableaux ci-dessous ; la part du prestataire est présentée à part.
Une PKI interne gérée par cert-manager (émetteur openkeel-ca) signe les certificats des services ; la CA de l'opérateur MariaDB signe ceux de la base. Chaque service vérifie le serveur auquel il parle.
| Flux | Protocole | Confiance |
|---|---|---|
| Clients → Ingress → API | HTTPS, rechiffré vers des backends HTTPS (Skyline, console Nova, wsproxy Zun) | Certificat public ; certificats internes cert-manager |
| API ↔ API | REST sur HTTPS, URL internes https dans le catalogue | PKI interne, émetteur cert-manager openkeel-ca |
| Services → MariaDB | SQL sur TLS, exigé par le serveur | CA de l'opérateur MariaDB, vérifiée par chaque service |
| Services → RabbitMQ | AMQPS (RPC et notifications) | PKI interne openkeel-ca |
| Neutron → OVN NB/SB | OVSDB sur ssl:, TLS mutuel | Certificats client et serveur OVN |
Plus de Memcached ni de Redis : aucun composant ne les lisait, et okadm les retire des installations existantes. Seuls les ports d'administration :9090 (santé, métriques), la distribution Erlang entre les nœuds RabbitMQ et la passerelle RGW de --ceph-s3 transportent encore du trafic en clair dans le cluster. Tout le tableau est dans le code (global.tls.internal, activé par défaut) et a été vérifié sur le lab le 2026-11-08.
Toute image qu'exécute un cluster de production vient du registre du prestataire : celles d'OpenKeel, construites depuis l'espace de travail, et celles des tiers, copiées avec leur SBOM. Les unes et les autres sont signées avec la clé du prestataire.
| Images | Registre | SBOM et provenance | Signature |
|---|---|---|---|
Services OpenKeel, okadm, site web | Construites par make release et poussées dans REGISTRY ; les charts y pointent (global.imageRegistry) | SBOM SPDX par plateforme et provenance SLSA, attachés par BuildKit dans l'index de l'image ; exportés par make sbom | cosign, par digest de l'index (make sign), attestations comprises |
Binaires okadm | Fichiers de version dans dist/cli, avec SHA256SUMS | SBOM SPDX par binaire (syft) | Sommes de contrôle |
| Prérequis : cert-manager, opérateurs MariaDB et RabbitMQ, MariaDB, RabbitMQ, Traefik | Copiées de registre à registre par make mirror-prereqs, toutes plateformes, un préfixe par registre amont | Le SBOM de l'éditeur quand la copie le conserve, sinon un SBOM syft attaché par cosign attest (MIRROR_SBOM=1) | Chaque copie signée avec la clé OpenKeel |
| Ironic (images Kolla amont) | Épinglées par digest dans le manifeste de version d'okadm, tirées via global.imageRegistry | Via le miroir (MIRROR_EXTRA_IMAGES) | Via le miroir |
Le cluster tire depuis le miroir sans modifier aucun chart : un hosts.toml par registre amont pour containerd, machine.registries.mirrors sous Talos. Aucune signature, aucun SBOM ni digest d'image n'est envoyé aux services publics de Sigstore (build/cosign/signing-config-private.json). Source : BUILD.md.
Fait dans le code et dans les charts, ou documenté pour le prestataire.
| Exigence | SecNumCloud 3.2 | État | Preuve | Prochaine étape |
|---|---|---|---|---|
| Maîtrise du code, pas de dépendance à un éditeur extra-européen | § 19 | Fait | Réécriture Go open source de Keystone, Nova, Neutron, Cinder, Glance, Manila, Barbican… (openkeel-*) ; aucune télémétrie ni appel sortant vers un tiers | Reconstruire les images dans une CI européenne |
| Journalisation des actions sur les API | chap. 12 | Fait | Un événement CADF par appel sur toutes les API (internal/audit), événements d'identité de Keystone (internal/notify), compteurs openkeel_audit_events_{sent,dropped,failed}_total | Ajouter le kube-apiserver et l'API Talos à la piste d'audit |
| Conservation et intégrité des journaux | chap. 12 | Fait | Documenté dans openkeel-chart/docs/audit-trail.md : archive WORM (object lock en mode compliance), 12 mois dont 3 en ligne (Loki 400 j), NTP sur les nœuds Talos, alertes sur les pertes, règles SIEM | Le prouver sur une plateforme réelle (prestataire) |
| Contrôle d'accès des API | chap. 9 | Fait | Politiques RBAC OpenStack (admin, member, reader, service, portées projet et système) appliquées par chaque service ; refus en 403 comme dans OpenStack, couverts par les tests de conformité | Réduire les comptes de service trop privilégiés |
| Gestion des secrets et des clés | chap. 10 | Fait | Barbican en Go avec un HSM PKCS#11 (internal/crypto/p11.go, tests SoftHSM) ou Vault / OpenBao ; rotation de la KEK (internal/manage/rotate.go) | HSM qualifié ANSSI en production |
| Cloisonnement des conteneurs clients | chap. 13 | Fait | Zun sous Kata Containers par défaut (RuntimeClass kata) : un noyau par conteneur client | — |
| Chiffrement du plan de contrôle réseau | chap. 10, 13 | Fait | OVN Northbound / Southbound en TLS mutuel (ssl:) entre Neutron, ovn-octavia-provider, FWaaS, VPNaaS, ovn-bgp-agent et OVN central | — |
| API optionnelles désactivables | chap. 13 | Fait | ec2-api peut être désactivé dans le Configurator (composant ec2-api de son catalogue) | — |
| Authentification multifacteur | chap. 9 | Fait | Keystone : méthode TOTP (internal/keystone/totp.go) et règles MFA par utilisateur (options.multi_factor_auth_rules, internal/api/mfa_test.go) | Fédération OIDC |
| Chiffrement des flux vers la base de données | chap. 10 | Fait | MariaDB en TLS obligatoire (infrastructure.mariadb.tls.required: true), CA de l'opérateur MariaDB vérifiée par tous les services (global.tls.trustedCAs, transmise par okadm à chaque release), tls=skip-verify refusé ; appliqué et vérifié sur le lab (require_secure_transport à ON) | Vérifier la réplication Galera en TLS sur un cluster à trois nœuds (le lab n'en a qu'un) |
| Suites TLS des listeners | chap. 10 | Fait | internal/tlsx dans les 16 services (copie de celui de Keystone) : TLS 1.2 minimum, ECDHE avec AES-GCM ou ChaCha20 seulement (guide TLS de l'ANSSI), certificat relu au renouvellement ; RabbitMQ limité à TLS 1.2/1.3 et aux suites AEAD | — |
| Surface d'attaque réduite : pas de service de données inutile | chap. 13 | Fait | Memcached et Redis supprimés : aucun composant ne les lisait ; okadm les retire des installations existantes (internal/deploy/retired.go) | — |
| Chiffrement de tous les flux internes | chap. 10 | Fait | global.tls.internal: true par défaut : AC interne cert-manager (openkeel-ca), un certificat par chart (ECDSA P-256, 90 jours) ; RabbitMQ en AMQPS seul ; URL internes et catalogue interne en https:// ; Ingress vers des backends HTTPS vérifiés (Traefik ServersTransport, annotations nginx) ; étape okadm rabbitmq-trust ; rapports d'état d'ovn-octavia-provider vers un écouteur TLS dédié de Neutron (openkeel-neutron-lbaas:9878, hors port d'administration). Vérifié sur le lab le 2026-11-08 : 18 points d'écoute en HTTPS avec certificat vérifié, HTTP clair refusé, connexions AMQP en TLS 1.3 | Capture réseau : aucun flux applicatif en clair hors :9090 |
| Intégrité et traçabilité des images OpenKeel | chap. 14 | Fait | Chaque image construite avec --sbom=true --provenance=mode=max (ATTEST=1, par défaut) : un SBOM SPDX par plateforme (paquets Debian de la base distroless, chaque module Go) et la provenance SLSA dans l'index de l'image ; make sbom les exporte dans dist/sbom, avec le SBOM de chaque binaire okadm ; make sign signe chaque index par digest avec cosign, ce qui couvre ses attestations (build/sbom.sh, BUILD.md) | Imposer les signatures à l'admission |
| Images tierces sur un registre maîtrisé, avec un SBOM | chap. 14 | Fait | make mirror-prereqs copie les images des prérequis (cert-manager, opérateurs MariaDB et RabbitMQ, MariaDB, RabbitMQ, Traefik : 14 images) de registre à registre, toutes plateformes, d'après le manifeste de version d'okadm ; containerd ou Talos redirigent chaque registre amont vers le miroir ; MIRROR_SBOM=1 exporte un SBOM par copie, en attache un par cosign attest quand l'éditeur n'en fournit pas, et signe chaque copie avec la clé OpenKeel ; les images OpenKeel et celles d'Ironic, épinglées par digest, sont tirées via global.imageRegistry | Recopier les images que KubeVirt et CDI déterminent à l'exécution |
Les numéros de chapitres orientent la lecture ; ils sont à vérifier sur le référentiel publié avant de construire la matrice de conformité. Source : openkeel-docs/SECNUMCLOUD-STATUS.md.
| Exigence | SecNumCloud 3.2 | État | Preuve | Prochaine étape |
|---|---|---|---|---|
| Suites TLS homogènes | chap. 10 | En cours | Services (tlsx) et RabbitMQ alignés ; reste le côté public des contrôleurs d'Ingress | Profil TLS ANSSI sur les points d'entrée publics de l'Ingress |
| Cohérence des charts | — | En cours | Conflit de noms du helper svc.volumes entre sous-charts (montage des CA de confiance) | Préfixer les helpers par chart |
| Images construites et contrôlées par le prestataire | chap. 14 | En cours | make release construit chaque image en multi-architecture depuis l'espace de travail (distroless sans root, UID 65532, sans shell) avec son SBOM, sa provenance et sa signature ; la configuration de signature par défaut n'utilise aucun des services publics de Sigstore (build/cosign/) ; Ironic tourne encore sur les images Kolla (Python) amont, recopiées par digest | Lancer make release dans une CI européenne ; remplacer les images Kolla |
| Veille des vulnérabilités des images | chap. 14 | En cours | make vuln (govulncheck, go mod verify) sur chaque module Go ; les SBOM des images OpenKeel et tierces s'analysent sans retirer les images (grype, trivy sbom) | Analyser les SBOM à chaque version et périodiquement pour les nouvelles CVE |
| Exigence | SecNumCloud 3.2 | État | Preuve | Prochaine étape |
|---|---|---|---|---|
| MFA des administrateurs via un IdP | chap. 9 | À faire | TOTP local seulement | Fédération OIDC dans Keystone (IdP européen, MFA porté par l'IdP), associée aux rôles |
| MFA des administrateurs Kubernetes | chap. 9 | À faire | Accès par kubeconfig à certificat client (okadm access) | OIDC et MFA vers le kube-apiserver, rôles Kubernetes nominatifs, pas de cluster-admin permanent |
| Configurator authentifié | chap. 9 | À faire | UI sans login ; son ClusterRole patche les nœuds et lit tous les journaux (deploy/kustomize/base/rbac.yaml) | Authentification OIDC, ClusterRole réduit, accès depuis le SI d'administration seulement |
| Comptes de service minimaux | chap. 9 | À faire | Rôle admin pour ec2-api (all_tenants), Masakari, Zun (binding:host_id), Skyline et neutron-vpnaas ; openstack-exporter avec le mot de passe admin | Rôles dédiés et règles de politique ciblées par service ; un exporter en lecture seule (reader système) |
| Exigence | SecNumCloud 3.2 | État | Preuve | Prochaine étape |
|---|---|---|---|---|
| Une clé par client pour les volumes | chap. 10 | À faire | Cinder enregistre la clé fixe 00000000-0000-0000-0000-000000000000 et délègue le chiffrement à la StorageClass | Lier Cinder à Barbican : une clé par volume chiffré, dans le projet du client |
| Chiffrement des disques | chap. 10 | À faire | — | Longhorn LUKS par volume ; chiffrement de MariaDB, Glance et Swift |
| Effacement en fin de contrat | chap. 19 | À faire | — | Effacement cryptographique : destruction des clés Barbican du projet, procédure tracée |
| Pas d'algorithme obsolète | chap. 10 | À faire | Signatures EC2 v0/v1 en HMAC-SHA1 acceptées par Keystone (internal/keystone/ec2sign.go) | Une option pour n'accepter que v2 (SHA-256) et v4, les anciennes désactivées par défaut en production |
| HSM qualifié | chap. 10 | À faire | PKCS#11 générique testé sur SoftHSM | Valider avec un HSM qualifié ANSSI |
| Exigence | SecNumCloud 3.2 | État | Preuve | Prochaine étape |
|---|---|---|---|---|
| Signatures imposées à l'admission | chap. 14 | À faire | Images signées et attestées, mais le cluster exécute n'importe quelle image | Kyverno verifyImages ou le policy-controller de Sigstore avec cosign.pub, pour les images d'OpenKeel comme pour celles des opérateurs |
| Exigence | SecNumCloud 3.2 | État | Preuve | Prochaine étape |
|---|---|---|---|---|
| SI d'administration séparé | chap. 9, 13 ; PA-022 | À faire | Une proposition écrite : zones Z1, Z2 et Z3 (openkeel-docs/SECNUMCLOUD-ADMIN-SI.md) | Réseau d'administration, bastion, postes d'administration (prestataire) |
| Plan de contrôle séparé du plan de données | chap. 13 | À faire | Un seul cluster Talos porte les API et les charges des clients | Étape 1 : durcissement en cluster unique, agents Nova et Zun centralisés (plus de DSN sur les hyperviseurs) ; cible : clusters de contrôle et de données séparés |
| Journalisation de l'administration de la plateforme | chap. 12 | À faire | Seules les API OpenStack sont tracées | Politique d'audit du kube-apiserver, journaux de l'API Talos, du bastion et des BMC, archivés comme la piste CADF |
| Ports d'administration chiffrés | chap. 10 | À faire | Santé et métriques sur :9090 en HTTP clair, dans le cluster ; les rapports d'état d'ovn-octavia-provider n'y passent plus : Neutron les reçoit sur un écouteur TLS dédié | TLS (ou mTLS Prometheus) sur :9090, ou une NetworkPolicy qui ne laisse entrer que Prometheus |
| Pas de télé-assistance extra-européenne | § 19.6 | À faire | Télé-assistance des baies de stockage (Pure1, accès distant du constructeur) non désactivée par OpenKeel | Documenter et vérifier leur désactivation dans le guide d'installation de production |
| Distribution Erlang de RabbitMQ | chap. 10 | À faire | Trafic entre les nœuds RabbitMQ (port 25672) non chiffré, dans le cluster | TLS de la distribution Erlang (ssl_dist), que l'opérateur ne gère pas |
Passerelle RGW (--ceph-s3) | chap. 10 | À faire | RGW joint Keystone en HTTPS vérifié (caBundleRef), mais sert S3 et Swift en HTTP clair sur le port 80 dans le cluster | Port sécurisé de RGW avec un certificat de l'AC interne |
| Appels d'okadm aux API | chap. 10 | À faire | Par le proxy de services de l'API Kubernetes en https: : chiffré, sans vérification du certificat des pods | Appeler par l'Ingress, ou vérifier côté client |
Les API OpenKeel font partie du service vendu aux clients : elles ne sont pas le SI d'administration. La proposition sépare donc trois zones, et les interfaces d'administration de Z2 et Z3 (kube-apiserver, API Talos, BMC, etcd, ports d'administration) ne sont joignables que depuis Z1.
| Zone | Contenu | Qui y accède |
|---|---|---|
| Z1, SI d'administration | Postes d'administration, bastion, IdP des administrateurs (MFA), runner okadm et dépôt Git des values, Configurator, collecte et stockage des journaux (Loki, SIEM, bucket WORM), miroir de registre signé | Administrateurs seulement, depuis leurs postes |
| Z2, plan de contrôle du service | API OpenKeel, conductors, schedulers, MariaDB, RabbitMQ, Barbican, Ingress public | Clients (API publiques via l'Ingress) ; administrateurs via Z1 |
| Z3, plan de données | Hyperviseurs (KubeVirt), nœuds Zun (Kata), stockage (Longhorn), passerelles réseau (passerelle OVN, BGP) | Clients (leurs VM et conteneurs) ; administrateurs via Z1 |
Recommandation de la proposition : un réseau d'administration et un cluster unique durci dès maintenant, dans tout déploiement de production ; des agents Nova et Zun centralisés comme premier développement ; des clusters de contrôle et de données séparés comme cible pour une offre qualifiée. Rien de tout cela n'est encore implémenté.
Terminer le TLS sur tous les flux internes, puis le vérifier par une capture réseau.
OIDC et MFA pour les administrateurs, chiffrement au repos avec une clé par client.
Images construites dans une CI européenne, signatures imposées à l'admission, SI d'administration et séparation des plans.
La matrice d'exigences, une revue interne, puis un pré-audit par un auditeur qualifié.
L'essentiel du référentiel concerne le prestataire qui opère le service. OpenKeel ne le remplace pas, mais il ne doit pas lui faire obstacle, et il fournit une partie des preuves.
Politique de sécurité, rôles, habilitations et formation du personnel. OpenKeel fournit des rôles nominatifs et la piste d'audit de leurs actions.
Centres de données, contrôle d'accès aux salles et au matériel. OpenKeel tourne sur les serveurs du prestataire, en France et en Europe.
Changements, sauvegardes, gestion des vulnérabilités et des capacités. okadm planifie, installe et met à jour un composant à la fois ; Grafana montre l'état de chaque service.
Détection, traitement et notification des incidents. La piste CADF, Loki et les alertes Prometheus apportent les faits.
§ 19.6 : actionnariat, localisation des données et support dans l'Union européenne. OpenKeel est open source, sans télémétrie ni appel sortant.
Configurations, politiques et journaux réunis dans la matrice de conformité, versionnée avec le code.
| Étape | Quoi | Résultat |
|---|---|---|
| Matrice d'exigences | SecNumCloud 3.2 chapitre par chapitre : porteur (OpenKeel ou prestataire), mécanisme, preuve | Matrice de conformité versionnée avec le code |
| Revue interne | Chaque preuve vérifiée sur une installation en mode production | Rapport de revue, écarts suivis |
| Pré-audit | Auditeur qualifié, sur une plateforme pilote complète | Rapport de pré-audit et plan de traitement |
| Test d'intrusion PASSI | API publiques, évasion de VM et de Kata vers le plan de contrôle, SI d'administration | Rapport, corrections et contre-test |
| CSPN (optionnelle) | Composants critiques : Keystone, Barbican, isolation Kata et KubeVirt | Certification de premier niveau des composants retenus |