OpenKeel : la solution Cloud souveraine, française à portée européenne du groupe inherent Découvrir inherent

Ressources

FAQ

Les réponses essentielles pour comprendre OpenKeel.

Qu'est-ce qu'OpenKeel ?

La solution Cloud souveraine, française à portée européenne du groupe inherent. Elle réécrit en Go les services d'OpenStack au-dessus de technologies Cloud Native (Kubernetes, OVN, KubeVirt, CSI). Ses API REST sont compatibles avec celles d'OpenStack et elle se déploie sur Kubernetes avec la CLI okadm.

Qui est derrière OpenKeel ?

Le groupe inherent, groupe IT français expert en IA, cloud, cybersécurité et connectivité pour les entreprises et les collectivités.

Sous quelle licence OpenKeel est-il distribué ?

La licence Apache 2.0, celle d'OpenStack : le code peut être utilisé, modifié et redistribué, y compris commercialement, avec une concession explicite de brevets ; la licence et les mentions de droit d'auteur accompagnent chaque copie, et les modifications sont signalées comme telles.

OpenKeel est-il qualifié SecNumCloud ?

SecNumCloud (ANSSI) qualifie un service et son prestataire, pas un logiciel. OpenKeel est conçu pour être SecNumCloud-ready : chaque flux interne en TLS, une piste d'audit CADF sur chaque API, le RBAC d'OpenStack, Barbican avec un HSM, l'isolation Kata des conteneurs, des images signées avec un SBOM sur un registre maîtrisé. Ce qui est conforme aujourd'hui et ce qui reste à faire évoluer, exigence par exigence, est sur SecNumCloud-ready.

Mes outils OpenStack fonctionnent-ils ?

Oui : chaque composant garde les chemins, paramètres, codes HTTP, corps d'erreur, microversions et policies de l'original. Clients, SDK, Terraform, Tempest et Skyline ne voient pas la différence. Les écarts connus sont listés dans le docs/CONFORMANCE.md de chaque module.

En quoi OpenKeel est-il multi-tenant ?

Les tenants sont ceux de Keystone (domaines, projets, rôles, quotas). Ils n'ont aucun accès Kubernetes. Les VMs n'ont pas d'interface sur le réseau des pods : leurs NIC sont des ports Neutron dans OVN, protégés par port_security et une garde CNI. Manila et Zun isolent aussi chaque tenant (passerelle NFS dans le réseau du tenant, microVM Kata par conteneur).

Pourquoi réécrire en Go ?

Go est le langage de Kubernetes, etcd, containerd, Helm, Prometheus et KubeVirt. Il donne des binaires statiques, des images distroless sans shell et un accès natif à client-go, au SDK Helm et à OVSDB.

Comment déployer OpenKeel ?

Avec okadm : okadm plan vérifie le cluster, okadm install installe opérateurs, services de données et composants dans l'ordre, okadm upgrade met à jour composant par composant. En lab, okadm peut créer un cluster kind.

Quelles baies de stockage sont supportées ?

Toute baie ou tout logiciel de stockage disposant d'un driver CSI bloc : Rook-Ceph (RBD), Longhorn, NetApp (Trident), Huawei Dorado, et Pure Storage FlashArray via le driver CSI d'OpenKeel. Chacun est un backend Cinder défini par une StorageClass ; les tenants le choisissent par les types de volume. Voir Stockage bloc pour l'état de validation de chaque driver.

Que devient le plan de données ?

Il n'est pas réécrit : KubeVirt exécute les VMs, OVN et Open vSwitch commutent les réseaux, CSI (Longhorn, Pure Storage) fournit les volumes, Rook-Ceph le stockage objet, ExternalDNS le DNS et Medik8s la remédiation des nœuds.

Ironic et Heat sont-ils réécrits ?

Pas encore. Ironic reste en Python amont, empaqueté dans un chart OpenKeel. Heat a sa reverse-spec ; seules ses commandes stack et orchestration sont réécrites dans le client ok.

Comment la compatibilité est-elle vérifiée ?

Par cinq niveaux de tests : unitaires, intégration Galera, replay e2e des échanges enregistrés auprès du service Python, différentiel CLI entre ok et openstack, et Tempest avec ses plugins.

D'où viennent les spécifications ?

De la skill generate-reverse-spec, qui lit le code Python amont d'une branche (stable/2026.2) et produit une spécification sourcée et un rewrite pack. Les 38 reverse-specs sont publiées dans la rubrique Ressources.