Plateforme d’exécution
Kubernetes quand il se justifie, une plateforme managée quand elle suffit
LUXIA Identity s’exécute aujourd’hui sur une plateforme managée. Cette page décrit cette exécution réelle, les critères qui justifieraient Kubernetes, et l’architecture visée pour les déploiements sur site et souverains.
Niveau de preuve :CibleAucune plateforme Luxia-IT ne fonctionne aujourd’hui sur Kubernetes. L’architecture de référence Kubernetes décrite plus bas est une cible.
Aujourd’hui
Une plateforme managée, par choix
Pour une plateforme et ce volume, une plateforme managée apporte l’isolation, les correctifs, le chiffrement en transit et la montée en charge des fonctions, sans cluster à exploiter.
| Charge | Où elle s’exécute |
|---|---|
| Interface et API | Niveau de preuve :Vérifié en productionFonctions serverless managées, sans état. Les sessions sont en base. |
| Données | Niveau de preuve :Vérifié en productionPostgreSQL managé, sécurité au niveau des lignes forcée. |
| Retour arrière | Niveau de preuve :Vérifié en productionPoint de restauration de la base avant chaque mise en production. |
| Sauvegardes | Niveau de preuve :Vérifié en productionDéclenchées et conservées hors de la plateforme applicative, chiffrées, dans l’Union européenne. |
Parcours
Ce qui arrive à une requête, étape par étape
Le chemin réel d’une requête dans LUXIA Identity aujourd’hui, de son arrivée à la reprise après incident. Chaque étape indique le composant qui agit et son niveau de preuve.
Arrivée
Composant : Plateforme managée
Le navigateur joint l’application en HTTPS. La plateforme termine le chiffrement TLS et achemine la requête vers une fonction applicative sans état.
Niveau de preuve :Vérifié en productionIdentité
Composant : Fonction applicative et base de données
La session est retrouvée par l’empreinte de son jeton, au moyen d’une fonction dédiée de la base de données. Une session expirée, révoquée ou rattachée à une organisation suspendue est refusée.
Niveau de preuve :Vérifié en productionPolitiques
Composant : Fonction applicative
L’autorisation évalue les droits explicites attribués à la personne dans son organisation. Les règles de séparation des tâches s’appliquent aux habilitations.
Niveau de preuve :Vérifié en productionCharge
Composant : Plateforme managée
La plateforme crée autant d’instances de la fonction que nécessaire. Aucune instance ne conserve d’état entre deux requêtes : toutes sont interchangeables.
Niveau de preuve :Vérifié en productionPersistance
Composant : PostgreSQL managé
La requête s’exécute dans le contexte de son organisation. PostgreSQL applique la sécurité au niveau des lignes, que le rôle de l’application ne peut pas contourner.
Niveau de preuve :Vérifié en productionAudit
Composant : Journal en ajout seul
Une action d’administration ou une connexion est ajoutée au journal. L’application ne peut ni modifier ni supprimer ces enregistrements.
Niveau de preuve :Vérifié en productionSupervision
Composant : Alerte externe
Une alerte émise hors de la chaîne de sauvegarde prévient l’opérateur si une sauvegarde manque. La supervision de l’application elle-même (disponibilité, erreurs, latence) est conçue, pas encore en service.
Niveau de preuve :ConçuReprise
Composant : Sauvegardes indépendantes
Des sauvegardes chiffrées sont conservées hors du fournisseur de base de données. Le 13 octobre 2026, la base a été reconstruite à partir de l’une d’elles et vérifiée en 81 secondes.
Niveau de preuve :Vérifié en productionDécider
Kubernetes n’est pas un gage de sérieux
Il ajoute une surface à sécuriser et à exploiter. Nous ne le retenons que si l’un des critères de droite s’applique.
Une plateforme managée suffit quand…
- Une seule application et peu de services à faire communiquer.
- Aucune obligation d’exécuter le logiciel chez le client.
- Une montée en charge que le fournisseur absorbe.
- Une exploitation assurée par une équipe réduite, sans cluster à maintenir.
Kubernetes devient pertinent pour…
- Déployer chez un client, sur son infrastructure ou dans un environnement isolé.
- Séparer plusieurs charges (interface, API, traitements asynchrones) avec des flux réseau explicites.
- Un conditionnement unique, portable d’un cloud à un site.
- Un client dont les équipes exploitent déjà Kubernetes.
Architecture cible
Architecture de référence Kubernetes
Visée pour les déploiements sur site et souverains. Chaque mesure ci-dessous est une cible : aucune n’est en service.
EntréePasserelle ou ingress · TLS · limitation de débit · protection WAF et DDoS
Zone A
- Interface
- API
- Traitements asynchrones
PostgreSQL primaire
Zone B
- Interface
- API
- Traitements asynchrones
Réplique synchrone
Zone C
- Interface
- API
- Traitements asynchrones
Réplique
Services partagés
- Stockage objet
- Coffre de secrets (Vault ou KMS)
- Registre d’images privé
- Observabilité (OpenTelemetry, Prometheus, Grafana)
Charges de travail
3 mesures
- Sans état
- Interface, API et traitements asynchrones dans des déploiements séparés. L’état vit dans PostgreSQL et le stockage objet.
- Remplacer ou déplacer une instance sans perte.
- Sondes
- Sondes de démarrage, de disponibilité et de vivacité distinctes.
- Ne recevoir du trafic qu’une fois prêt ; redémarrer ce qui est bloqué.
- Ressources
- Requests et limits sur chaque conteneur.
- Placement prévisible, aucun voisin bruyant.
Disponibilité et charge
3 mesures
- Trois zones
- Répartition par topology spread constraints et règles d’anti-affinité.
- Survivre à la perte d’une zone.
- PodDisruptionBudget
- Un nombre minimal de répliques disponibles pendant les maintenances.
- Les mises à jour du cluster ne coupent pas le service.
- Mise à l’échelle
- Horizontal Pod Autoscaler sur l’API et les traitements ; autoscaling du cluster.
- Absorber la charge sans surdimensionner.
Exposition
3 mesures
- Entrée
- Ingress ou passerelle d’API ; TLS terminé à l’entrée, certificats renouvelés automatiquement.
- Un seul point d’entrée, contrôlé.
- Limitation de débit
- Par client et par route sensible : connexion, récupération, inscription.
- Freiner l’énumération et la force brute.
- WAF et DDoS
- Protection du fournisseur en cloud ; celle du client sur site.
- Filtrer avant l’application.
Réseau, identité et secrets
4 mesures
- NetworkPolicy
- Tout flux refusé par défaut ; chaque flux autorisé explicitement.
- Une instance compromise ne joint pas le reste.
- Identité de charge de travail
- Les instances s’authentifient auprès du cloud et du coffre sans secret stocké.
- Aucun secret de longue durée à voler.
- Secrets
- Vault, KMS ou équivalent, avec rotation ; jamais dans les images ni dans les dépôts.
- Un secret se révoque sans reconstruire.
- Chiffrement
- TLS en transit, y compris entre services lorsque l’environnement l’exige ; volumes et sauvegardes chiffrés au repos.
- Les données d’identité restent illisibles hors de la plateforme.
Données
5 mesures
- PostgreSQL haute disponibilité
- Primaire et répliques réparties sur les zones, bascule automatique.
- Les données d’identité sont relationnelles et isolées par ligne.
- Redis
- Non retenu par défaut. Seulement pour un besoin mesuré, comme une limitation de débit partagée entre répliques.
- Chaque composant ajouté se sécurise et s’exploite.
- File d’événements
- Non retenue par défaut. Seulement si des traitements asynchrones, comme les notifications ou les exports, la justifient.
- Même raison.
- Stockage objet
- Archives du journal, exports et sauvegardes.
- Conservation longue hors de la base.
- Isolation des clients
- Isolation par ligne dans une instance partagée ; instance dédiée par client sur site et en souverain.
- Le niveau d’isolation suit le modèle de déploiement.
Chaîne d’approvisionnement
4 mesures
- Registre privé
- Images servies depuis un registre du périmètre.
- Indispensable en environnement isolé.
- Images signées
- Signature à la construction, vérification à l’admission dans le cluster.
- Seul ce qui a été construit et revu s’exécute.
- SBOM
- Nomenclature logicielle publiée avec chaque version.
- Savoir ce qu’une version contient.
- Analyse
- Images et dépendances analysées à chaque construction ; publication bloquée sur une vulnérabilité critique.
- Ne pas livrer une faille connue.
Livraison
3 mesures
- Helm ou Kustomize
- Un conditionnement versionné, paramétré par environnement.
- Le même artefact partout.
- GitOps
- Argo CD ou Flux : l’état du cluster suit un dépôt revu.
- Chaque changement a un auteur, une revue et un retour arrière.
- Déploiements
- Progressifs par défaut ; canary ou blue/green pour les changements à risque.
- Limiter l’effet d’une erreur.
Observabilité
5 mesures
- OpenTelemetry
- Traces, métriques et journaux instrumentés d’une seule façon.
- Un même langage pour tous les signaux.
- Prometheus et Grafana
- Métriques et tableaux de bord.
- Voir l’état du service.
- Journaux centralisés
- Sans donnée sensible ni secret.
- Enquêter sans exposer.
- Traces distribuées
- Une connexion suivie de bout en bout.
- Localiser une lenteur ou une erreur.
- Alertes sur objectifs de service
- Alerter sur la consommation du budget d’erreur, pas sur chaque symptôme.
- Réveiller pour ce qui compte.
Continuité
4 mesures
- Sauvegardes vérifiées
- Restaurées régulièrement dans un environnement vide, comme sur la plateforme actuelle.
- Une sauvegarde non restaurée n’est pas une preuve.
- Actif-passif ou multi-région
- Seulement lorsque l’objectif de reprise le justifie.
- Chaque région ajoutée a un coût d’exploitation.
- RTO et RPO
- Fixés avec chaque client, puis vérifiés par exercice.
- Un objectif non mesuré n’engage personne.
- Exercices de reprise
- Planifiés, chronométrés et consignés.
- La procédure doit fonctionner le jour où elle sert.
Objectifs
Aucun objectif de service n’est publié à ce jour
Disponibilité, RTO et RPO se fixent avec chaque client, puis se vérifient par des exercices consignés. Les seules mesures publiées ici sont celles d’exercices datés, sur la plateforme actuelle.
Un déploiement sur votre infrastructure ?
Parlons de vos contraintes d’exécution : nous dirons ce qui existe, ce qui reste à construire et ce que cela suppose de votre côté.