Plateforme AKKO vs environnement client simulé — les 3 périmètres¶

En bref¶

Le déploiement AKKO sur demo.akko-ai.com (Netcup) est un cluster de développement et de démonstration. Pour prouver la valeur AKKO lors d'une visite prospect, nous gardons trois périmètres strictement séparés :

Périmètre	Représente	Qui le possède chez un vrai client
1. AKKO core	La plateforme : cockpit, Keycloak (clients internes), OPA, ADEN, Trino, OpenMetadata, observabilité, Postgres state	AKKO livre et opère ceci
2. Identity provider	LLDAP peuplé comme une vraie entreprise (50+ users en OU Engineering / Finance / Compliance / Sales) — séparé d'AKKO	L'AD / LDAP / Okta / Azure AD existant du client
3. Sources de données	Hive sur un mini-Cloudera kerberisé, Postgres / Oracle XE / MS SQL Express — séparés d'AKKO	Le data warehouse, lakehouse, OLTP existants du client

Les trois périmètres vivent dans trois namespaces Kubernetes différents sur le cluster démo (akko, akko-demo-ad, akko-demo-cloudera, akko-demo-sources). AKKO core les traite comme des endpoints externes — exactement comme chez un vrai client.

Pourquoi cette séparation est essentielle¶

Un prospect qui visite demo.akko-ai.com ne doit jamais se demander « mais ça marchera-t-il avec MON AD ? » — parce que nous pouvons lui montrer, en live, que AKKO se connecte à un LLDAP séparé peuplé comme une vraie entreprise. Le login se fait contre l'AD démo ; AKKO n'a pas créé ces utilisateurs. La fédération est configurée, pas seedée.

Idem pour les données : le prospect voit ADEN questionner une table hive.warehouse.transactions qui vit sur un cluster HDFS+Hive kerberisé dans son propre namespace. AKKO n'a pas seedé Hadoop ; il l'a découvert et fédéré. C'est exactement la configuration one-shot qu'un admin client ferait sur son installation Cloudera CDP existante.

Ce qu'est vraiment « AKKO core »¶

Le chart Helm umbrella akko livre ces sub-charts comme la plateforme :

cockpit — application admin single-page, le seul que les end-users consultent
akko-keycloak — IdP local pour le realm AKKO (clients, service accounts) ; la fédération utilisateurs est configurée pour pointer sur l'AD du client
akko-opa — décisions d'autorisation fine pour Trino, ADEN, ai-service
akko-aden — pipeline langage naturel → SQL → dashboard, scope-first OPA + cache multi-tier + catalogue sémantique vector (ADR-041/042/043)
akko-ai-service — couche RBAC LLM
trino + akko-polaris — fédération + moteur de requête Iceberg
openmetadata — catalogue sémantique
akko-postgres — état de la plateforme (log audit, cache ADEN, metadata dashboards)
akko-storage (SeaweedFS) — couche storage objet
akko-observability (Perses + VictoriaLogs + Prometheus + alertmanager)

Une installation chez un vrai client livre uniquement ces charts. Aucune donnée démo. Aucun utilisateur seedé. Aucune base démo. Le client connecte ses sources existantes après que helm install ait fini, via :

Keycloak User Federation pointant sur son AD / LDAP
La page « Add catalog » du cockpit qui enregistre des catalogs Trino sur les endpoints Hive / Postgres / Oracle / SQL Server du client

Ce qui vit dans les périmètres client simulés¶

Ce sont des charts uniquement démo qui sont livrés dans le repo AKKO pour montrer le produit, mais qui ne sont jamais installés chez un vrai client :

akko-demo-ad — LLDAP + seed 50 users + 4 OU + un petit CSV de mapping rôles
akko-demo-cloudera — namenode + datanode + Hive Metastore + KDC MIT Kerberos + un schéma warehouse avec 10k rows seed
akko-demo-sources — Postgres climascore-db (données réalistes) + Oracle XE 21c + MS SQL Express, chacun avec des schémas seed

Un client qui déploie le umbrella mettra explicitement akko-demo-ad.enabled=false, akko-demo-cloudera.enabled=false, akko-demo-sources.enabled=false. Le chart-by-default les a déjà désactivés (voir Sprint 56 D6 zero-hardcoding).

La user story pour une démo prospect¶

Le founder ouvre https://identity.demo.akko-ai.com (l'UI web LLDAP de l'AD client simulé) et montre 50 utilisateurs groupés en Engineering, Finance, Compliance, Sales. Il en choisit un — disons j.dupont@acme.demo.
Le founder ouvre https://demo.akko-ai.com, se logue en j.dupont (dont les credentials vivent dans l'AD démo, pas dans AKKO). Le cockpit affiche le bon badge de rôle dérivé du groupe AD Finance → rôle AKKO akko-analyst.
Le founder ouvre la page « Catalogs » : 5 catalogs baseline (Postgres state, tpch, tpcds, jmx, iceberg) — ce sont des internals plateforme AKKO — plus hive, climascore, oracle_demo, mssql_demo — ce sont les sources client simulées. Chaque carte montre son badge tech.
Le founder demande à ADEN : « Affiche les 10 plus gros marchands ce trimestre depuis le warehouse ». Le panel de raisonnement ADEN montre qu'il a interrogé Milvus, filtré les tables candidates via OPA allowed_tables pour j.dupont, demandé au LLM de générer le SQL contre hive.warehouse.transactions, exécuté via Trino avec l'identité de j.dupont, retourné 10 rows.
Le founder demande une requête cross-source : « Croise ces marchands avec ceux de notre base climascore qui ont un score de risque climatique élevé ». ADEN génère un JOIN entre hive.warehouse.transactions et climascore.public.scores, exécute via Trino.

Tout au long, le prospect voit que AKKO n'a pas seedé les utilisateurs, n'a pas seedé les données, n'a pas installé d'agents sur Hadoop. AKKO est la couche fédération + gouvernance + IA ; ses données et son AD restent là où ils sont.

Plan en sprints¶

Le split est livré en trois sprints — voir akko-technical-map/sprints/sprint-61-3-perimeters-vision.md (repo privé) pour le détail :

Sprint 61.1 — extraire LLDAP dans le namespace akko-demo-ad, peupler des utilisateurs réalistes, configurer Keycloak User Federation par Helm values.
Sprint 61.2 — chart akko-demo-cloudera : HDFS + Hive Metastore + KDC + données seed + fédération Trino via le connector Hive.
Sprint 61.3 — akko-demo-sources : Postgres / Oracle XE / MS SQL Express, chacun enregistré via l'UI Add Catalog du cockpit.

Installer le périmètre 2 — `akko-demo-ad` (Sprint 61.1)¶

Le chart standalone vit dans helm/akko-demo-ad/. Il est séparé du chart umbrella akko — installé en tant que release Helm distincte, dans son propre namespace.

Installation rapide (cluster de démo)¶

# 1. Générer deux mots de passe out-of-band — JAMAIS les commiter
ADMIN_PW=$(openssl rand -hex 16)
USER_PW=$(openssl rand -hex 16)

# 2. Créer le namespace + installer le chart
kubectl create ns akko-demo-ad
helm install akko-demo-ad helm/akko-demo-ad/ -n akko-demo-ad \
  -f helm/examples/values-demo-ad.yaml \
  --set adminPassword="$ADMIN_PW" \
  --set bootstrap.defaultUserPassword="$USER_PW"

# 3. Attendre la fin du Job de bootstrap (50 utilisateurs, 9 groupes)
kubectl -n akko-demo-ad wait --for=condition=complete job \
  -l app.kubernetes.io/component=bootstrap --timeout=5m

# 4. Vérification : un utilisateur du seed doit s'authentifier sur le
#    Service DNS interne (et non via l'Ingress — egress DNS-only).
kubectl -n akko-demo-ad logs job -l app.kubernetes.io/component=bootstrap \
  | grep "auth verification"
# attendu : [+] auth verification: 50 pass / 0 fail (out of 50)

Connecter AKKO core à l'AD de démo¶

Dans l'overlay umbrella AKKO (par ex. values-netcup.yaml), pointer Keycloak User Federation sur le Service in-cluster du périmètre 2 :

akko-keycloak:
  userFederation:
    enabled: true
    provider: ldap
    url: "ldap://akko-demo-ad-akko-demo-ad.akko-demo-ad.svc.cluster.local:3890"
    bindDn: "uid=admin,ou=people,dc=akko,dc=local"
    baseDn: "dc=akko,dc=local"
    usersDn: "ou=people,dc=akko,dc=local"
    bindCredentialSecret:
      name: akko-demo-ad-federation
      key:  bind-password

Copier le mot de passe admin depuis le secret du périmètre 2 vers le namespace AKKO pour que Keycloak puisse binder en lecture seule :

ADMIN_PW=$(kubectl -n akko-demo-ad get secret akko-demo-ad-akko-demo-ad \
  -o jsonpath='{.data.admin-password}' | base64 -d)
kubectl -n akko create secret generic akko-demo-ad-federation \
  --from-literal=bind-password="$ADMIN_PW"

Installation client réel (BYO-IdP)¶

Ne pas installer akko-demo-ad du tout. Pointer userFederation.url sur le LDAP du client, stocker les bind credentials dans un secret créé manuellement (out-of-band), et la même release AKKO fonctionne sans aucune modification.

Forme du seed bootstrap¶

Le chart livre 50 utilisateurs répartis en 4 OUs et 5 groupes de rôles plateforme :

Groupe OU	Utilisateurs	Distribution rôles plateforme
`org-engineering`	20	mix admins / engineers / analysts / stewards / viewers
`org-finance`	12	majoritairement analysts + viewers + 2 stewards
`org-compliance`	10	majoritairement stewards + viewers
`org-sales`	8	viewers + 2 analysts

Les 5 groupes de rôles plateforme (akko-admins, akko-engineers, akko-analysts, akko-stewards, akko-viewers) sont mappés 1:1 sur les realm roles AKKO via le paramètre global.auth.ldap.roleMapping de la release umbrella.

Anti-patterns interdits¶

Hardcoding : aucun nom de rôle, hostname, password, compte utilisateur dans le code. Tout via Helm values + secrets ; le chart-by- default les laisse vides (audit-hardcoded-identities.py retourne 0 hits).
Bricolage : chaque fix est permanent. Pas de workaround verifyJwt: false qui masque un vrai issuer mismatch. Pas de kubectl set env non documenté qui s'évapore au prochain helm upgrade.
Nommage vendor : pages, env vars, dashboards sont layer-named (par ex. dashboards, metrics, logs), jamais vendor-named (Grafana, Loki, MinIO). Le client n'a pas à savoir quel moteur tourne sous le capot.
Half-migrations (pattern Sprint 39.5) : quand un swap a lieu, ratisser toutes les références consumer-side dans la même PR + ajouter un gate de régression.

Voir aussi¶

sprint-61-3-perimeters-vision.md (privé) — décomposition complète des sprints
customer-onboarding.fr.md — comment un vrai client installe AKKO core
ADR-039 — pas d'identités hardcodées
ADR-041 / 042 / 043 — ADEN scope-first OPA + cache multi-tier + catalogue vector