Une journée (riche) aux Cloud Native Days France 2026 (Partie 1/2)

Le mardi 3 Février 2026, Ippon Technologies était présente au Cloud Native Days France (anciennement Kubernetes Community Days) le salon du Cloud Native, du DevOps et de la souveraineté 3 ans après la première édition en 2023. L'ensemble de l'équipe présente ce jour là vous propose de revenir sur la Keynote d'ouverture qui était particulièrement intéressante et sur certaines des conférences qui nous ont marqués.

Keynote : souveraineté, open source et retours terrain

La journée s’est ouverte sur un sujet aussi sérieux que brûlant : la souveraineté numérique. Introduite avec une pointe d’humour, la question n’en est pas moins préoccupante. Le contexte géopolitique actuel, et en particulier la dépendance aux acteurs américains du cloud, fait peser un risque réel sur la confidentialité et la maîtrise de nos données.

Rapidement, une question centrale s’impose : où place-t-on le curseur de la souveraineté ?

Si l’on est boulanger, la problématique peut sembler lointaine. Pour une administration, un organisme de recherche ou une entreprise stratégique, elle devient critique. A cela, l’équipe derrière les CNDs a une réponse: l’open source, à condition de ne pas s’en contenter comme simple consommateur. Contribuer financièrement, par du code, de la documentation ou du temps est indispensable pour garantir la pérennité d'un l’écosystème indépendant des GAFAM et des gouvernements. Un véritable appel à contribution collective.

Plusieurs intervenants se sont ensuite succédé pour illustrer ces enjeux par des cas concrets.

CERN : traiter des pétaoctets sans faire exploser le budget

Le premier retour d’expérience venait du CERN (Organisation européenne pour la recherche nucléaire), célèbre pour son accélérateur de particules. Le défi est colossal : traiter des pétaoctets de données chaque seconde tout en maîtrisant les coûts, grâce à une infrastructure cloud native couplée à de l’IA.

L’objectif principal est de fournir aux chercheurs des environnements de travail clés en main (CPU, RAM, GPU) sans qu’ils aient à se soucier de Kubernetes ou des conteneurs, qui peuvent être intimidants. Kubernetes devient ici un outil d’abstraction au service d’une plateforme IA.

D’un point de vue technique, plusieurs optimisations ont été mises en avant :

• CPU pinning et NUMA affinity pour éviter la contention entre workloads,
• partage fin des GPU,
• optimisations réseau avec RDMA.

La transition progressive des calculs CPU vers GPU pose toutefois un problème majeur : la consommation énergétique, les GPU consommant même lorsqu’ils sont inactifs. D’où l’intérêt des Dynamic Resource Claims, permettant de n’allouer que les ressources strictement nécessaires, au bon moment.

DINUM & DGFIP : mutualiser pour devenir souverains

Les représentants de la DINUM (Direction interministérielle du Numérique) et de la DGFiP (Direction Générale des Finances Publiques) ont ensuite rappelé l’importance de la souveraineté et du SecNumCloud. Leur stratégie repose sur une offre basée sur OpenStack, opérée par des cloud providers certifiés SecNumCloud comme OVHcloud et Outscale.

L’enjeu principal : une convergence interministérielle pour mutualiser les ressources cloud et les services.  Cela se matérialise notamment par l’offre Kubo, une distribution Kubernetes managée sous licence Apache 2.0 (Open Source) qui vient avec un certain nombre de caractéristiques comme la sécurité by design, le FinOps, le DevSecOps, du Namespace as a Service, de la souveraineté etc.

Scaleway : la souveraineté par la maîtrise de toute la stack

Troisième intervention marquante : Scaleway, représentée par Jean-Baptiste Kempf, l’un des fondateurs de VLC. Leur vision de la souveraineté est claire : maîtriser toute la stack technique, à l’exception du matériel.

Cela passe par :

• la compilation interne des briques logicielles,
• une forte contribution à l’open source (Kubernetes, kernel Linux, hyperviseur…),
• une approche “des développeurs pour des développeurs”.

Tout est accessible par API (Go, JS, Python via SDK…), et la vélocité est impressionnante. En deux ans, l’offre a radicalement évolué, tant en richesse fonctionnelle qu’en maturité. Un message fort en ressort : un cloud souverain français, c’est possible.

Table ronde : Kubernetes, formation et platform engineering

La table ronde a soulevé une question récurrente : est-il encore utile de se former à Kubernetes à l’ère du tout managé ?

La réponse est nuancée. Le principe “You build it, you run it” reste pertinent, à condition de bien définir les responsabilités (ownership) et de maintenir une communication fluide entre équipes. Certains développeurs hésitent à porter la responsabilité de la production sans comprendre ce qui se passe “sous le capot”.

Un consensus émerge :

• former tout le monde, notamment les développeurs,
• éviter le silo des équipes,
• assumer pleinement une culture DevOps.

Un autre point clé a été martelé : la documentation. Essentielle, mais trop souvent négligée ou rapidement obsolète.

Enfin, attention aux dérives du platform engineering : une plateforme trop restrictive peut conduire au shadow IT 🔥. D’où la métaphore parlante entre Golden Cage (prison dorée mais contraignante) et Golden Path (parcours guidé, mais flexible). Le facteur clé reste le travail transverse et la curiosité mutuelle entre équipes.

NumSpot et la communauté open source

NumSpot a ensuite présenté sa plateforme de services cloud Data & IA, fondée il y a trois ans avec l’ambition d’être une alternative souveraine. Elle repose largement sur des outils open source, avec des services managés et du Kubernetes.

Enfin, tosit.fr a rappelé l’importance des communautés locales, qui jouent un rôle essentiel dans la diffusion, le partage et la pérennisation de l’open source.

Pourquoi “Cloud Native Days” et plus “Kubernetes Community Days” ?

Pour conclure, les organisateurs ont expliqué le changement de nom de l’événement. Initialement appelé Kubernetes Community Days, le salon était soumis aux contraintes de la Cloud Native Computing Foundation, tant sur la taille des événements que sur la ligne éditoriale. En devenant Cloud Native Days, les organisateurs gagnent en liberté et en ouverture.

Bonne nouvelle au passage : une nouvelle édition verra le jour dès cette année à Aix-en-Provence.

REX DINUM - Les ingrédients multitenancy et authentification pour une distribution k8s open-source française

Vincent Piard, de la DINUM, a présenté les coulisses techniques de Kubo, la distribution Kubernetes développée par la DGFIP. L'objectif du talk n'était pas de faire une démonstration produit, mais plutôt de dévoiler les briques open source et les choix d'architecture qui permettent de construire une plateforme "Namespace as a Service" sécurisée, multi-tenant et déployable sur plusieurs cloud providers (Scaleway, Outscale, OVHcloud).

L'analogie du Parc d'Attractions : penser la gouvernance autrement

Pour rendre la gestion des droits plus accessible, Vincent a filé une métaphore astucieuse : celle du parc d'attractions "CNDLand". Dans ce parc, les namespaces deviennent des attractions, et les utilisateurs des visiteurs aux profils variés. On y retrouve les classiques "Owners" et "Utilisateurs", mais aussi des profils plus colorés comme le "Super-owner" (le directeur du parc) ou "l'utilisateur maladroit Jar Jar" (celui qui appuie sur tous les boutons). Cette approche permet de définir finement qui a le droit de faire quoi, et surtout, qui peut casser quoi et où.

Vincent a également distingué deux modèles de multi-tenancy, chacun répondant à des besoins d'isolation différents :

• Multi-tenancy par équipe (ex : équipe charpentiers vs équipe décors) : les workloads peuvent communiquer entre eux avec un certain niveau de confiance mutuelle.
• Multi-tenancy par commanditaire (ex : client Disneyland vs client Parc Astérix) : nécessite une isolation forte et stricte, car les tenants ne se font pas confiance.

Le choix du multi-tenancy : de HNC à Capsule

La question du multi-tenancy était centrale pour Kubo. Comment permettre à plusieurs équipes ou administrations de partager une même infrastructure Kubernetes tout en garantissant l'isolation et la sécurité ? L'avantage est clair : avec une seule infrastructure globale plutôt qu'un cluster par client, la maintenance devient beaucoup plus simple. Lorsqu'une modification est apportée, elle profite automatiquement à tous les tenants.

Le premier choix : HNC (Hierarchical Namespace Controller)

L'équipe s'est d'abord tournée vers HNC (Hierarchical Namespace Controller), un projet prometteur qui proposait un système de namespaces hiérarchiques avec héritage de droits. L'idée était séduisante : un namespace "root" avec des namespaces enfants qui héritent automatiquement des configurations et des droits de leur parent. Malheureusement, le projet a été abandonné par manque de contributions de la communauté, rendant son utilisation trop risquée pour une infrastructure critique de l'administration française.

La solution retenue : Capsule

C'est finalement Capsule, un projet CNCF Sandbox, qui a été retenu. Et pour cause : Capsule répond parfaitement au besoin en offrant une expérience proche du "cluster admin" sans jamais le devenir réellement.

Capsule : un micro-écosystème pour le multi-tenancy

Capsule implémente un environnement multi-tenant policy-based directement dans Kubernetes. Sa philosophie ? Rester minimaliste et s'appuyer uniquement sur les mécanismes natifs de Kubernetes (pas de CRD complexe, pas de modification du control plane). C'est un écosystème pensé comme une architecture micro-services, léger et maintenable.

Le concept central de Capsule est le Tenant (locataire). Un Tenant regroupe plusieurs namespaces sous une même administration, avec une isolation forte vis-à-vis du reste du cluster. Cette isolation permet de :

• Empêcher les utilisateurs d'un tenant d'accéder aux ressources des autres tenants
• Appliquer des politiques de sécurité et des quotas au niveau du tenant
• Déléguer l'administration à des propriétaires sans leur donner les privilèges cluster-wide

Configuration d'un Tenant : le cœur de la gouvernance

Voici un exemple de configuration d'un Tenant présenté durant le talk, qui illustre toute la puissance de Capsule :

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: espace
spec:
  owners:
    - kind: Group
      name: "oidc:/espace/kube/owners" # Mappé depuis Keycloak
      clusterRoles:
        - admin
  additionalRoleBindings:
    - clusterRoleName: view
      subjects:
        - kind: Group
          name: "oidc:/espace/kube/readers"

Cette configuration définit :

• Les propriétaires du tenant (owners) : ici, un groupe Keycloak qui obtient les droits admin sur tous les namespaces du tenant
• Des bindings additionnels : par exemple, donner des droits en lecture seule (view) à un autre groupe
• Une isolation totale : les propriétaires peuvent créer et gérer leurs namespaces, mais n'ont aucune visibilité sur les autres tenants du cluster

L'architecture repose sur trois niveaux de configuration :

1. Configuration globale du cluster : gérée par les administrateurs Kubernetes
2. Configuration des Tenants : créée par les cluster admins, définit les propriétaires et les politiques
3. Gestion des namespaces : déléguée aux propriétaires des tenants, qui peuvent créer et administrer leurs espaces en autonomie

Les limites de Capsule : le problème de la visibilité

Aussi puissant soit-il, Capsule présente une limitation importante : les utilisateurs ne peuvent voir que les ressources à l'échelle d'un namespace. Concrètement, si vous essayez de lister tous vos namespaces avec kubectl get ns, la commande échoue. Pourquoi ? Parce que lister les namespaces est une permission "cluster-scoped" que Capsule ne peut pas accorder sans compromettre l'isolation.

C'est ici qu'intervient Capsule Proxy, un composant complémentaire indispensable.

Capsule Proxy : l'ingrédient secret pour la visibilité

Capsule Proxy agit comme un Man-In-The-Middle intelligent entre l'utilisateur et l'API Server Kubernetes. Son fonctionnement est astucieux :

1. L'utilisateur exécute kubectl get ns
2. Capsule Proxy intercepte la requête
3. Il exécute la commande avec ses propres privilèges élevés (il peut lister tous les namespaces)
4. Il filtre les résultats pour ne renvoyer que les namespaces appartenant au Tenant de l'utilisateur

Résultat : l'utilisateur obtient une vue claire de ses namespaces, exactement comme s'il était cluster admin, mais sans jamais avoir ce privilège. C'est cette combinaison Capsule + Capsule Proxy qui offre une véritable expérience "Namespace as a Service" sans compromettre la sécurité globale du cluster.

Moderniser l'authentification avec OIDC et Kubelogin

Pour compléter cette architecture multi-tenant, l'équipe a modernisé la chaîne d'authentification. Fini les anciens flags en ligne de commande du kube-apiserver ! Place à une Configuration d'Authentification structurée (AuthenticationConfiguration), disponible depuis Kubernetes 1.30.

Cette approche permet de déléguer proprement l'identité à Keycloak via OIDC :

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
  - issuer:
      url: https://security.cndland/realms/cndland # Keycloak URL
      audiences:
        - kubernetes
      claimMappings:
        username:
          claim: "email"
          prefix: ""
        groups:
          claim: "groups"
          prefix: "oidc:" # Les groupes Keycloak deviennent oidc:groupname

Côté utilisateur, Kubelogin (un plugin kubectl) simplifie drastiquement l'expérience : il intercepte les demandes d'authentification et ouvre automatiquement le navigateur pour connecter l'utilisateur via Keycloak. Plus besoin de manipuler des certificats ou des tokens complexes.

Un catalogue d'opérateurs pour l'autonomie

Enfin, pour compléter l'offre, Kubo propose un catalogue d'opérateurs accessible aux utilisateurs. Puisque ces derniers ne sont pas admins des clusters, ce catalogue leur permet de déployer facilement des services managés (bases de données, systèmes de cache, etc.) sans intervention de l'équipe plateforme.

Conclusion : une plateforme souveraine et contributive

Cette approche illustre parfaitement l'ambition de Kubo : offrir aux administrations françaises une plateforme Kubernetes souveraine, sécurisée et moderne, tout en restant 100% open source (licence Apache 2.0) et contributive à l'écosystème Cloud Native. Le choix de Capsule, projet CNCF, s'inscrit dans cette démarche de contribuer à l'open source plutôt que de simplement le consommer.

Afin de ne pas surcharger cet article, nous vous donnons rendez-vous dans un prochain article pour lire la suite de notre journée.