← Accueil · Stacks & langages · Toute la doc

Spring Boot sur OKS + Kafka + PostgreSQL + Redis + Keycloak

Le schéma type des grandes entreprises et des scale-ups Java : des microservices Spring Boot derrière une gateway, Kafka pour les événements, PostgreSQL pour les données, Redis pour le cache, Keycloak pour l’identité. Sur OKS, le Kubernetes managé d’Outscale, disponible aussi en Région SecNumCloud, bige-ops génère le cluster, les manifests et le chiffrage.

flowchart TB
  U["Internet"] -->|"HTTPS"| LG["LBU · gateway"]
  U -->|"HTTPS"| LW["LBU · web"]
  U -->|"HTTPS · OIDC"| LK["LBU · Keycloak"]
  subgraph OKS ["OKS · cp.3.masters.small · 3 × tinav6.c8r16p2"]
    GW["api · Spring Cloud Gateway
HPA 2 → 6"]
    WEB["web · SPA"]
    KC["Keycloak 26.8"]
    OR["orders · Spring Boot"]
    CA["catalog · Spring Boot"]
    WK["worker · consumers Kafka"]
    KF[("Kafka 4.3 · KRaft")]
    PG[("PostgreSQL 17")]
    RD[("Redis 8")]
  end
  LG --> GW
  LW --> WEB
  LK --> KC
  GW --> OR
  GW --> CA
  GW -.->|"jetons OIDC"| KC
  OR --> PG
  CA --> PG
  OR --> KF
  KF --> WK
  GW --> RD
  PG -.->|"pg_dump"| OOS[("OOS · backups")]
      

Pourquoi cette stack tourne bien sur Outscale

• Kubernetes managé, rien qu’à toi : OKS te donne un cluster dédié, avec son control plane isolé et sans partage de ressources. Tu déploies tes services, Outscale opère le cluster. OKS
• Un réseau privé et des sauvegardes sûres : Tes bases restent dans le réseau privé de ton projet, jamais exposées à Internet. Les sauvegardes partent vers l’Object Storage, compatible S3 et répliqué entre plusieurs zones.
• Prêt pour les clients exigeants : Régions qualifiées SecNumCloud 3.2 pour le secteur public, certification HDS pour la santé. Pourquoi Outscale · SecNumCloud 3.2

Architecture sur Outscale

• Control plane cp.3.masters.small : 3 masters, haute disponibilité, jusqu’à 50 nœuds. C’est le niveau qu’Outscale recommande pour la production.
• Nodepool de 3 nœuds tinav6.c8r16p2. La somme des demandes mémoire de la simulation (gateway et microservices à 1 GiB par réplica, Kafka 2 GiB, PostgreSQL 2 GiB, Keycloak 1 GiB…) tient autour de 14 GiB : la marge absorbe l’HPA et les déploiements progressifs.
• Gateway (api, Spring Cloud Gateway, HPA de 2 à 6 réplicas sur 70 % de CPU), web, et deux microservices orders et catalog déclarés en services custom avec leur image de registre (2 réplicas chacun).
• Kafka (image officielle apache/kafka:4.3.1, mode KRaft) et Keycloak (quay.io/keycloak/keycloak:26.8.1, commande start) en services custom ; PostgreSQL 17 et Redis 8 du catalogue bige-ops.
• Les pods de données démarrent sur emptyDir : le filet est le backup PostgreSQL vers OOS, activé ici. Pour un Kafka multi-brokers à stockage persistant, un opérateur comme Strimzi s’ajoute ensuite dans ton exploitation (périmètre).

Coût mensuel estimé

Calculé avec bige-ops estimate --json sur le catalogue public Outscale synchronisé le 17 septembre 2026, Région eu-west-2, en € HT par mois (730 heures). Estimation indicative, sur la grille publique ; le trafic sortant est à 0 € HT au catalogue public de cette Région.

LBU des Services exposés. La gateway, le front et Keycloak sont trois Services LoadBalancer : trois LBU à 21,90 € HT par mois l’unité au même catalogue, soit 65,70 € de plus : 984,50 € HT par mois au total. Faire passer Keycloak derrière la gateway en retire un.

Le projet utilisé, à reproduire chez toi :

bige-ops init -n stack-spring-boot-oks-kafka-keycloak
bige-ops add layout custom --name platform --runtime java --web spa --worker \
  --db postgres --db redis --topology oks --lbu
# puis project.yaml ajusté comme ci-dessous
bige-ops validate
bige-ops estimate --json

name: stack-spring-boot-oks-kafka-keycloak
region: eu-west-2
components:
- type: stack
  name: platform
  topology: oks
  services: [api, web, worker, postgres, redis, orders, catalog, kafka, keycloak]
  images: {postgres: 'postgres:17', redis: 'redis:8-alpine'}
  control_plane: cp.3.masters.small
  nodepools:
  - {name: default, type: tinav6.c8r16p2, count: 3}
  service_config:
    postgres:
      backup: {enabled: true, oos_bucket: platform-backups}
    api:
      hpa: {enabled: true, min: 2, max: 6, target_cpu: 70}
    orders: {kind: custom, image: 'registry.example.com/platform/orders:1.0.0', port: 8080,
      memory_mb: 1024, replicas: 2}
    catalog: {kind: custom, image: 'registry.example.com/platform/catalog:1.0.0', port: 8080,
      memory_mb: 1024, replicas: 2}
    kafka: {kind: custom, image: 'apache/kafka:4.3.1', port: 9092, memory_mb: 2048}
    keycloak:
      kind: custom
      image: quay.io/keycloak/keycloak:26.8.1
      port: 8080
      memory_mb: 1024
      command: [start]
      expose: true
- {type: oos_bucket, name: platform-backups, bucket: platform-backups, size: 100, purpose: backups}

Données et middlewares : versions, backups, failles connues

PostgreSQL. PostgreSQL 18 (supporté jusqu’en novembre 2030), 17 (novembre 2029), 16 (défaut bige-ops, novembre 2028) et 15 (novembre 2027) sont maintenus ; 14 sort du support le 12 novembre 2026. La simulation épingle postgres:17. Source : politique de versions PostgreSQL. Côté durcissement : un rôle applicatif dédié (jamais le superutilisateur), des règles pg_hba.conf limitées au CIDR du Net en scram-sha-256, et des mises à jour mineures régulières (la majeure reste celle que tu épingles).

Redis. La simulation garde redis:8-alpine, le tag par défaut de bige-ops : il suit la dernière Redis 8. Épingle la mineure (par exemple 8.10) si tu veux un build strictement reproductible. Côté durcissement : un mot de passe ou des ACL, le protected mode actif, aucune exposition publique, et les commandes d’administration réservées à un utilisateur dédié (sécurité Redis).

Kafka. Kafka 4 fonctionne sans ZooKeeper (mode KRaft). Écoute sur le réseau du cluster seulement, authentification SASL/SCRAM ou mTLS entre clients et brokers, ACL par topic. Doc : Kafka · image apache/kafka · côté Spring : Spring for Apache Kafka (ses failles connues).

Keycloak. Mode production (start) avec KC_HOSTNAME sur ton domaine, base PostgreSQL dédiée plutôt que la base embarquée, console d’administration réservée à tes CIDR. Le TLS se termine sur le LBU : configure Keycloak pour les en-têtes du proxy. Doc : Keycloak · Keycloak en conteneur.

Le backup est activé dans la simulation (backup.enabled + bucket OOS) : bige-ops crée le bucket, protégé contre la destruction, et prépare backup.sh (bucket, endpoint, planning) où tu branches le dump. Sans backup, Visual, preflight et plan te le signalent. Détail : OOS & backups.

Exposition : ce qui est ouvert, et à qui

• Entrées publiques : la gateway Spring Cloud (api), le front (web) et Keycloak (expose: true). Chacune est un Service LoadBalancer, donc un LBU Outscale ; le HTTPS se branche avec expose.tls.server_certificate_id (ORN d’un certificat EIM) et le LBU termine le TLS, sans Ingress ni cert-manager à maintenir.
• Bases et brokers : Services internes (ClusterIP), joignables seulement depuis le cluster. Jamais de type: LoadBalancer ni de NodePort vers une base.
• API Kubernetes : à l’apply, l’accès admin du cluster est restreint à ton IP publique (/32) ou au CIDR de OKS_ADMIN_CIDR.
• Nœuds : workers jetables gérés par OKS ; ne fonde aucune règle sur leurs IP.
• Keycloak : la page de connexion et les endpoints OIDC sont publics par nature ; la console /admin ne l’est pas, filtre-la ou sers-la sur un hostname d’administration séparé.

Détail : OKS & pods, réseau · ouvrir ou non, load balancers dans OKS.

Vulnérabilités : ce que bige-ops vérifie

Des failles, il y en aura toujours : l’important est de voir d’abord celles qui sont exposées. Avec ta clé OpenCVE, bige-ops compare les composants de ta stack, y compris les images de tes Dockerfile et docker-compose, au registre mondial des vulnérabilités (CVE), puis classe tout par urgence : ce qui est exposé à Internet d’abord. Pourquoi le refaire toi-même ? C’est chez toi, sur ton poste, et c’est gratuit. La méthode complète : ce que bige-ops vérifie.

Avec ta clé API OpenCVE (Settings), l’onglet Vulnérabilités lit ta simulation : chaque composant reconnu, image Docker ou paquet installé, est rapproché de sa fiche éditeur / produit, à raison d’une requête par produit. Les failles connues qui remontent sont classées par risque :

• Gravité : chaque faille a une note sur 10 (CVSS) ; critique dès 9, haute dès 7, moyenne dès 4. Une faille déjà exploitée par des attaquants (elle figure sur la liste KEV de la CISA, l’agence américaine de cybersécurité) compte au moins comme haute.
• Exposition dans ta simulation : un composant joignable depuis Internet, directement ou derrière le LBU, garde sa gravité ; un composant en subnet privé descend d’un cran, sauf si la faille est déjà exploitée.
• Départage : à risque égal, les failles déjà exploitées d’abord, puis la note sur 10, puis la probabilité d’être exploitée prochainement (EPSS). Le filtre « important » ne garde que les failles déjà exploitées ou notées 7 et plus.

Le rapprochement se fait au niveau du produit, pas de la version : à toi de recouper avec la version que tu as épinglée. Une image en latest ressort en plus comme « version non épinglée ». Le résultat est mis en cache dans la simulation et se rafraîchit à la demande.

L’analyse du code Java arrive ; ta stack est déjà couverte : composants et images comparés aux failles connues avec OpenCVE, exposition sur OKS et coût sur Outscale. Détail : Java sur Outscale.

Ce que bige-ops vérifie avant le deploy

• bige-ops validate : structure du projet, services custom (une image est requise pour un pod), HTTPS par expose.tls.server_certificate_id (ORN EIM).
• bige-ops preflight : clés Outscale présentes, OMI résolue, stack déclarée, IP des hôtes après l’apply, Dockerfile trouvé, secrets de build et d’exécution présents dans le coffre, jeton GitHub pour les dépôts privés, et alerte si une base n’a pas de backup vers OOS. Une erreur bloque le deploy.
• bige-ops plan : le plan Terraform et les specs OKS avant tout apply, avec les risques de perte de données signalés ; les buckets OOS sont protégés contre la destruction.
• Vulnérabilités : composants de la stack comparés aux failles connues avec OpenCVE et classés selon leur exposition, images en latest signalées, dépôts relus sur ton poste, sans clé ni IA.

OpenCVE, la source des failles connues

Pour savoir quelles failles connues touchent les briques de ta stack, bige-ops s’appuie sur OpenCVE. OpenCVE rassemble les failles publiées dans le registre mondial des vulnérabilités (CVE) et ses sources officielles (NVD, MITRE, liste KEV des failles déjà exploitées tenue par la CISA, l’agence américaine de cybersécurité…), donne à chacune sa note de gravité sur 10 (CVSS) et sa probabilité d’être exploitée (EPSS), et les range par éditeur et par produit, consultables dans son explorateur. Le projet est open source : son code, ses issues et les contributions de sa communauté vivent sur GitHub, et il s’installe aussi chez toi. Merci à ses mainteneurs et à tous ceux qui font vivre ce référentiel : c’est grâce à eux que chaque composant de ta simulation a sa fiche de failles à jour.

Docs officielles

• Spring Boot
• Spring Cloud
• Apache Kafka
• Keycloak
• OKS
• Load balancers dans OKS
• SecNumCloud

Langages : Java · Kotlin · Scala.

Pour aller plus loin : layouts & topologies, VMs, OKS, volumes BSU, OOS, LBU, réseau, régions, bases de données, catalogue de prix. Toutes les stacks : stacks & langages.