Aller au contenu

Architecture de gouvernance -- Modèle d'accès à trois dimensions

AKKO implémente une gouvernance des données de niveau entreprise avec trois dimensions orthogonales : Rôle plateforme, Équipe métier et Projet. Un seul jeton JWT Keycloak porte toutes les informations de gouvernance, appliquées de manière cohérente à travers chaque service de la plateforme.

+------------------------------------------------------------------+
|                       Jeton JWT Keycloak                         |
|                                                                  |
|  preferred_username: "carol"                                     |
|  groups: ["akko-analyst", "equipe-marketing", "projet-scoring"]  |
|                                                                  |
|  Dimension 1 : Rôle plateforme --> Quels OUTILS vous utilisez   |
|  Dimension 2 : Équipe métier   --> Quelles RESSOURCES partagées |
|  Dimension 3 : Projet          --> Quelles DONNÉES accessibles  |
+------------------------------------------------------------------+
         |                 |                    |
         v                 v                    v
   +-----------+    +-------------+    +----------------+
   |   Trino   |    |    object storage    |    |  Politique OPA |
   |  Superset |    |  Répertoires|    |  Filtres ligne |
   |  Airflow  |    |  partagés   |    |  Masquage col. |
   |  LiteLLM  |    |             |    |  Accès schéma  |
   +-----------+    +-------------+    +----------------+

Pourquoi trois dimensions ?

Les plateformes traditionnelles confondent rôles et accès aux données dans une seule hiérarchie. AKKO les sépare : une analyste marketing et une analyste fraude peuvent avoir le même rôle plateforme (toutes deux akko-analyst) mais voir des données complètement différentes (l'une travaille sur projet-scoring, l'autre sur projet-risk). Pendant ce temps, elles partagent le stockage d'équipe avec leurs départements respectifs. Ce modèle passe de 5 utilisateurs à 5 000 sans restructuration.

Les trois dimensions

Dimension 1 : Rôle plateforme

Les rôles plateforme contrôlent quels outils et capacités un utilisateur peut accéder à travers tous les services AKKO.

Rôle Persona Outils Niveau de ressources Accès modèles IA
akko-admin Administrateur plateforme Tous les services, consoles admin, DDL/DML Illimité Tous les modèles
akko-engineer Ingénieur données Spark, Airflow, Trino DDL, MLflow, notebooks Élevé (16 Go, 8 CPU) Tous les modèles
akko-analyst Analyste données senior Trino SELECT, Superset, notebooks, tableaux de bord Moyen (8 Go, 4 CPU) Modèles standard
akko-user Analyste conformité Trino SELECT (masqué), OpenMetadata, journaux d'audit Moyen (8 Go, 4 CPU) Modèles standard
akko-viewer Cadre / lecteur de tableaux de bord Tableaux de bord Superset, vues filtrées Bas (4 Go, 2 CPU) Modèles chat uniquement

Les rôles plateforme sont des rôles realm Keycloak, émis dans le claim JWT groups. Ils sont orthogonaux à l'accès aux données -- un akko-analyst dans l'équipe fraude voit des données différentes d'un akko-analyst dans le marketing.

Dimension 2 : Équipe métier

Les équipes métier représentent la structure organisationnelle. Elles contrôlent les ressources partagées, pas l'accès aux données.

Équipe Membres exemples Ressources partagées
equipe-marketing Carol, Frank shared/equipe-marketing/ dans object storage
equipe-data-eng Bob, Grace shared/equipe-data-eng/ dans object storage
equipe-fraude Eve, Hector shared/equipe-fraude/ dans object storage

Les équipes sont des groupes directory service synchronisés vers Keycloak. Elles apparaissent dans le claim JWT groups aux côtés des rôles plateforme.

Les équipes ne sont PAS du contrôle d'accès

L'appartenance à une équipe seule ne donne aucun accès aux données. Elle fournit un stockage d'équipe partagé dans object storage et un regroupement logique dans OpenMetadata. L'accès aux données est contrôlé exclusivement par l'appartenance au projet (Dimension 3).

Dimension 3 : Projet

Les projets contrôlent l'accès aux données. Ils déterminent quels schémas Trino, tables Iceberg, préfixes object storage et domaines OpenMetadata sont accessibles à un utilisateur.

Projet Périmètre de données Membres (inter-équipes)
projet-scoring iceberg.scoring.*, object storage projects/scoring/ Carol (marketing), Bob (data-eng)
projet-risk iceberg.risk.*, object storage projects/risk/ Eve (fraude), Grace (data-eng)

Les projets sont inter-équipes : des membres de différentes équipes métier collaborent sur les mêmes données. Chaque projet possède :

  • Un groupe directory service (ex. projet-scoring)
  • Un compte de service Keycloak pour les pipelines batch
  • Un préfixe object storage (projects/{name}/)
  • Des règles d'accès schéma Trino dans OPA
  • Un domaine OpenMetadata
  • Des politiques de masquage de colonnes et de filtrage de lignes

Modèle de stockage -- Variables JWT object storage

AKKO utilise l'évaluation de politique JWT à l'exécution dans object storage -- pas de création de bucket par utilisateur, pas de politiques IAM statiques.

Principes de conception

Principe Implémentation
Pas de création de bucket par utilisateur Bonne pratique de l'industrie -- les buckets sont structurels, pas liés à l'identité
Évaluation JWT à l'exécution object storage évalue ${jwt:preferred_username} et ${jwt:groups} à chaque requête
Création paresseuse de préfixe utilisateur Les répertoires par utilisateur sont créés au premier upload, pas au provisionnement
Zéro provisionnement à la création d'utilisateur Ajouter un utilisateur à Keycloak + groupe directory service suffit

Structure des buckets

minio/
├── analytics/              # Entrepôt Iceberg (géré par Polaris)
│   ├── scoring/            # Tables projet-scoring
│   ├── risk/               # Tables projet-risk
│   └── shared/             # Données de référence inter-projets
├── production/             # Comptes de service uniquement (pas d'accès interactif)
│   ├── airflow/            # Artefacts DAG, journaux
│   └── mlflow/             # Artefacts de modèles
├── projects/
│   ├── scoring/            # Espace de travail projet-scoring
│   │   ├── raw/            # Données brutes uploadées
│   │   ├── processed/      # Résultats intermédiaires
│   │   └── exports/        # Livrables
│   └── risk/               # Espace de travail projet-risk
├── shared/
│   ├── equipe-marketing/   # Fichiers partagés d'équipe
│   ├── equipe-data-eng/    # Fichiers partagés d'équipe
│   └── equipe-fraude/      # Fichiers partagés d'équipe
└── users/
    ├── carol/              # Espace personnel (créé au premier upload)
    ├── bob/                # Espace personnel
    └── eve/                # Espace personnel

Variables de politique JWT

Les politiques object storage référencent directement les claims JWT :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": [
        "arn:aws:s3:::users/${jwt:preferred_username}/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": [
        "arn:aws:s3:::shared/${jwt:groups}/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": [
        "arn:aws:s3:::projects/${jwt:groups}/*"
      ]
    }
  ]
}

Aucune gestion statique d'utilisateur dans object storage

Quand Carol rejoint projet-scoring, un administrateur l'ajoute au groupe directory service. À sa prochaine connexion, son JWT contient projet-scoring dans le claim groups. object storage évalue cela à l'exécution -- zéro configuration object storage requise.

Comptes de service

Accès interactif vs automatisé

Aspect Interactif (humain) Automatisé (pipeline)
Identité JWT personnel (connexion Keycloak) Compte de service (client_credentials)
Authentification Flux OIDC navigateur client_id + client_secret
Source du jeton Session utilisateur Keycloak Secret K8s monté dans le pod
Quota de ressources Niveau par rôle (4-16 Go) Niveau batch (64 Go, 20 exécuteurs)
Cycle de vie Lié à l'emploi de la personne Lié au cycle de vie du projet
Piste d'audit preferred_username dans les logs svc-projet-scoring dans les logs

Architecture des comptes de service

Projet : projet-scoring
    |
    +-- Client Keycloak : svc-projet-scoring
    |   ├── Type de grant : client_credentials
    |   ├── Groupes : ["projet-scoring", "svc-accounts"]
    |   └── Périmètre : données du projet uniquement
    |
    +-- Secret K8s : svc-projet-scoring-credentials
    |   ├── client_id : svc-projet-scoring
    |   └── client_secret : <généré>
    |
    +-- Connexion Airflow : projet_scoring_trino
    |   └── Utilise le jeton svc-projet-scoring
    |
    +-- Application Spark :
        └── Monte le Secret K8s, obtient le JWT à l'exécution

Quotas de ressources

Type de quota Interactif Batch (compte de service)
Mémoire max 8 Go 64 Go
CPU max 4 coeurs 16 coeurs
Exécuteurs Spark 4 20
Requêtes simultanées 5 20
LiteLLM RPM 60 300

Pourquoi les comptes de service sont importants

  1. Continuité des pipelines : quand Carol quitte projet-scoring, son accès personnel est révoqué. Le compte de service svc-projet-scoring continue d'exécuter les pipelines nocturnes sans interruption.
  2. Séparation de l'audit : les requêtes interactives sont journalisées sous le nom d'utilisateur humain. Les opérations batch sont journalisées sous le compte de service. Piste d'audit claire.
  3. Isolation des ressources : les utilisateurs interactifs ont des quotas modestes pour l'exploration. Les jobs batch ont des quotas généreux pour les charges de travail de production. Pas de contention de ressources.

Masquage de colonnes (inspiré de Starburst)

AKKO fournit 8 masques de colonnes prédéfinis plus des expressions personnalisées, inspirés du modèle de masquage de Starburst mais entièrement gérés via OPA.

Masques prédéfinis

Nom du masque Expression Exemple entrée Exemple sortie Types compatibles
SHA-256 to_hex(sha256(cast(col as varbinary))) alice@akko.io a1b2c3d4e5... VARCHAR, CHAR
SHA-512 to_hex(sha512(cast(col as varbinary))) alice@akko.io f6e5d4c3b2... VARCHAR, CHAR
MD5 to_hex(md5(cast(col as varbinary))) alice@akko.io d41d8cd98f... VARCHAR, CHAR
NULL CAST(NULL AS <type>) 2024-01-15 NULL Tous types
Masquer '***REDACTED***' +33612345678 ***REDACTED*** VARCHAR, CHAR
4 premiers substr(col, 1, 4) \|\| '****' 4242424242 4242**** VARCHAR, CHAR
4 derniers '****' \|\| substr(col, -4) 4242424242 ****4242 VARCHAR, CHAR
Année seule date_trunc('year', col) 1990-05-23 1990-01-01 DATE, TIMESTAMP
Personnalisé Expression SQL Trino définie par l'utilisateur (varie) (varie) (dépend de l'expression)

Propriétés des masques

  • Réutilisables : un masque est défini une fois et appliqué à de nombreuses colonnes à travers de nombreuses tables. Modifier la définition du masque met à jour toutes les colonnes qui l'utilisent.
  • Sensibles au type : le panneau d'administration cockpit n'affiche que les masques compatibles pour chaque type de colonne. Vous ne pouvez pas appliquer 4 premiers à une colonne DATE.
  • Par projet : les masques sont limités aux projets. projet-scoring peut masquer email avec SHA-256, tandis que projet-risk le masque avec Masquer.
  • Priorité : quand un utilisateur appartient à plusieurs projets avec des masques différents sur la même colonne, le masque le plus restrictif l'emporte.

Exemple de masquage de colonnes OPA

package trino

import rego.v1

# Charger les règles de masquage depuis les données OPA
masks := data.governance.column_masks

columnMask := {"expression": expression, "identity": identity} if {
    table := input.action.resource.table.tableName
    column := input.action.resource.column.columnName
    user_groups := input.context.identity.groups

    # Trouver le masque applicable pour cette colonne dans les projets de l'utilisateur
    some project in user_groups
    mask_rule := masks[project][table][column]

    # L'utilisateur n'est pas exempté (les admins voient les données en clair)
    not "akko-admin" in user_groups

    expression := mask_rule.expression
    identity := concat("_", ["mask", project, table, column])
}

Gestion des masques dans le cockpit

Le panneau d'administration cockpit fournit une interface visuelle pour gérer les masques de colonnes :

  1. Naviguer vers Administration > Gouvernance > Masquage de colonnes
  2. Sélectionner un projet (ex. projet-scoring)
  3. Parcourir les tables et colonnes disponibles
  4. Pour chaque colonne, sélectionner un masque dans le menu déroulant (filtré par type de colonne)
  5. Cliquer sur Appliquer -- les données de politique OPA sont mises à jour en temps réel

Sécurité au niveau des lignes

La sécurité au niveau des lignes (RLS) restreint les lignes qu'un utilisateur peut voir, basée sur l'appartenance au projet.

Principes de conception

Principe Implémentation
Par projet, pas par utilisateur Les filtres sont définis au niveau du projet. Tous les membres du projet voient les mêmes lignes.
Constructeur visuel Le panneau d'administration cockpit fournit un constructeur de filtres sans code
Opérateurs sensibles au type L'interface n'affiche que les opérateurs compatibles pour chaque type de colonne
Combinaison ET Plusieurs filtres sur la même table sont combinés avec ET (AND)
Exceptions utilisateur Des exceptions individuelles peuvent être accordées pour des utilisateurs spécifiques

Constructeur de filtres

Le constructeur visuel dans le panneau d'administration cockpit :

+--------------------------------------------------------------+
|  Filtre de lignes : projet-scoring / iceberg.scoring.transactions |
|                                                              |
|  Table :     [transactions    v]                             |
|  Colonne :   [region          v]                             |
|  Opérateur : [IN              v]                             |
|  Valeur :    [EMEA, APAC         ]                           |
|                                                              |
|  + Ajouter un autre filtre                                   |
|                                                              |
|  Filtres actifs :                                            |
|  1. region IN ('EMEA', 'APAC')                               |
|  2. amount > 100                                             |
|  Combiné : region IN ('EMEA','APAC') AND amount > 100        |
+--------------------------------------------------------------+

Opérateurs par type de colonne

Type de colonne Opérateurs disponibles
VARCHAR / CHAR =, !=, IN, NOT IN, LIKE, IS NULL, IS NOT NULL
INTEGER / BIGINT / DOUBLE =, !=, <, >, <=, >=, BETWEEN, IN, IS NULL
DATE / TIMESTAMP =, !=, <, >, <=, >=, BETWEEN, IS NULL
BOOLEAN =, IS NULL, IS NOT NULL

Exemple de filtre de lignes OPA

package trino

import rego.v1

# Charger les règles de filtrage de lignes depuis les données OPA
filters := data.governance.row_filters

rowFilters contains {"expression": expression, "identity": identity} if {
    table := input.action.resource.table.tableName
    user_groups := input.context.identity.groups

    # Trouver le filtre applicable pour cette table dans les projets de l'utilisateur
    some project in user_groups
    filter_rule := filters[project][table]

    # L'utilisateur n'est pas exempté (les admins voient toutes les lignes)
    not "akko-admin" in user_groups

    expression := filter_rule.expression
    identity := concat("_", ["filter", project, table])
}

Exceptions utilisateur

Dans des cas exceptionnels, des utilisateurs individuels peuvent obtenir un accès plus large que la valeur par défaut de leur projet :

{
  "user_overrides": {
    "carol": {
      "projet-scoring": {
        "transactions": {
          "override": "region IN ('EMEA', 'APAC', 'NA')",
          "reason": "Analyse inter-régions approuvée par le DPO le 2026-03-10",
          "expires": "2026-06-10"
        }
      }
    }
  }
}

Les exceptions sont :

  • Auditées : chaque exception enregistre qui l'a approuvée et pourquoi
  • Limitées dans le temps : les exceptions ont une date d'expiration
  • Visibles dans le cockpit : le panneau d'administration affiche les exceptions actives avec un badge d'avertissement

Modèle de politique OPA

OPA est le moteur de politique central pour toutes les décisions de gouvernance des données dans AKKO. Il évalue l'accès Trino, le masquage de colonnes et le filtrage de lignes à l'exécution en utilisant les données de trois couches.

Trois couches de données

+------------------------------------------------------------------+
|                     Magasin de données OPA                       |
|                                                                  |
|  Couche 1 : group_policies  (règles d'accès principales)        |
|  ├── projet-scoring                                              |
|  │   ├── schemas : ["scoring"]                                   |
|  │   ├── column_masks : {transactions.email: "sha256", ...}      |
|  │   └── row_filters : {transactions: "region IN ('EMEA')"}      |
|  └── projet-risk                                                 |
|      ├── schemas : ["risk"]                                      |
|      ├── column_masks : {customers.ssn: "redact", ...}           |
|      └── row_filters : {customers: "risk_score > 50"}            |
|                                                                  |
|  Couche 2 : user_overrides  (exceptions individuelles)           |
|  └── carol                                                       |
|      └── projet-scoring.transactions : filtre région élargi     |
|                                                                  |
|  Couche 3 : service_accounts (règles de pipeline batch)          |
|  └── svc-projet-scoring                                          |
|      ├── schemas : ["scoring"]                                   |
|      └── column_masks : {}   (pas de masquage pour l'ETL)        |
+------------------------------------------------------------------+

Règles de fusion des périmètres

Quand un utilisateur appartient à plusieurs projets, son accès est l'UNION de tous les périmètres de projet :

Règle Comportement Exemple
Accès schéma UNION Carol dans projet-scoring + projet-risk voit les schémas scoring.* et risk.*
Masquage de colonnes Le plus restrictif l'emporte Si projet-scoring masque email avec SHA-256 et projet-risk le masque avec Masquer, Carol voit Masquer
Filtres de lignes Combinaison ET (AND) Si les deux projets filtrent transactions, les deux filtres s'appliquent
Accès table UNION Carol voit les tables des deux projets

Flux d'évaluation

Requête utilisateur : SELECT email FROM scoring.transactions WHERE amount > 1000

  1. Extraction JWT
     ├── utilisateur : carol
     └── groupes : [akko-analyst, equipe-marketing, projet-scoring]

  2. Vérification d'autorisation (autoriser/refuser)
     ├── Rôle plateforme : akko-analyst --> SELECT autorisé
     └── Périmètre projet : projet-scoring --> scoring.* autorisé
     Résultat : AUTORISÉ

  3. Masquage de colonnes
     ├── Colonne : email
     ├── Masque projet : projet-scoring.transactions.email = SHA-256
     └── Exemption rôle : akko-analyst n'est PAS exempté
     Résultat : to_hex(sha256(cast(email as varbinary)))

  4. Filtrage de lignes
     ├── Table : scoring.transactions
     ├── Filtre projet : region IN ('EMEA', 'APAC')
     └── Exception utilisateur : aucune
     Résultat : WHERE region IN ('EMEA','APAC') AND amount > 1000

  5. Requête finale (réécrite par Trino) :
     SELECT to_hex(sha256(cast(email as varbinary))) AS email
     FROM scoring.transactions
     WHERE region IN ('EMEA','APAC') AND amount > 1000

Cycle de vie d'un projet

Créer un projet

Quand un administrateur crée un nouveau projet depuis le panneau d'administration cockpit, les ressources suivantes sont provisionnées automatiquement :

Étape Action Service
1 Créer le groupe directory service projet-{nom} directory service
2 Synchroniser le groupe vers Keycloak Keycloak (fédération LDAP)
3 Créer le compte de service svc-projet-{nom} Keycloak (client_credentials)
4 Stocker les identifiants client en Secret K8s Kubernetes
5 Créer le préfixe object storage projects/{nom}/ object storage
6 Créer le schéma Trino iceberg.{nom} Trino (via requête admin)
7 Enregistrer les données de politique OPA pour le projet OPA
8 Créer le domaine OpenMetadata OpenMetadata 
# Exemple : le cockpit déclenche cette séquence via des appels API
# 1. Créer le groupe directory service
curl -X POST http://akko-lldap:17170/api/graphql \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -d '{"query":"mutation { createGroup(name: \"projet-scoring\") { id } }"}'

# 2. Keycloak se synchronise automatiquement via la fédération LDAP

# 3. Créer le compte de service
curl -X POST http://akko-keycloak:8080/admin/realms/akko/clients \
  -H "Authorization: Bearer $KC_TOKEN" \
  -d '{"clientId":"svc-projet-scoring","serviceAccountsEnabled":true,...}'

# 4. Stocker dans K8s
kubectl create secret generic svc-projet-scoring-credentials \
  --from-literal=client_id=svc-projet-scoring \
  --from-literal=client_secret=$GENERATED_SECRET

# 5. Créer le préfixe object storage (paresseux -- créé à la première écriture)

# 6. Créer le schéma Trino
trino --execute "CREATE SCHEMA IF NOT EXISTS iceberg.scoring"

# 7. Enregistrer les données de politique OPA
curl -X PUT http://akko-opa:8181/v1/data/governance/group_policies/projet-scoring \
  -d '{"schemas":["scoring"],"column_masks":{},"row_filters":{}}'

# 8. Créer le domaine OpenMetadata
curl -X POST http://openmetadata:8585/api/v1/domains \
  -d '{"name":"scoring","description":"Domaine du projet scoring"}'

Ajouter un membre

  1. L'administrateur ajoute l'utilisateur au groupe directory service projet-{nom}
  2. À la prochaine connexion de l'utilisateur, le JWT inclut projet-{nom} dans le claim groups
  3. OPA évalue la nouvelle appartenance au groupe au moment de la requête
  4. object storage accorde l'accès à projects/{nom}/ en se basant sur les groupes JWT
  5. Aucun redémarrage de service requis

Retirer un membre

  1. L'administrateur retire l'utilisateur du groupe directory service
  2. À la prochaine connexion de l'utilisateur, le JWT ne contient plus le groupe du projet
  3. OPA refuse l'accès aux schémas du projet et n'applique aucun masque spécifique au projet
  4. object storage refuse l'accès au préfixe du projet
  5. Les pipelines ne sont pas affectés -- le compte de service svc-projet-{nom} continue de fonctionner

Délai d'expiration du jeton

Les jetons JWT existants restent valides jusqu'à leur expiration (par défaut : 5 minutes). Pour une révocation immédiate, forcez la déconnexion de l'utilisateur via l'API Admin Keycloak.

Archiver un projet

Étape Action
1 Passer les schémas Trino en lecture seule dans OPA (retirer INSERT/DELETE)
2 Passer le préfixe object storage en lecture seule (retirer PutObject)
3 Désactiver le compte de service dans Keycloak
4 Marquer le domaine OpenMetadata comme archivé
5 Conserver les données pour la conformité (période de rétention configurable)

Patterns entreprise

Recherche industrielle

Le modèle de gouvernance d'AKKO est basé sur l'étude des principales plateformes de données d'entreprise :

Plateforme Approche Équivalent AKKO
Databricks Unity Catalog Hiérarchie Metastore > Catalogue > Schéma > Table Projet > Schéma > Table avec application OPA
Snowflake Compte > Base de données > Schéma avec hiérarchie de rôles Rôle plateforme + Projet avec périmètre basé sur JWT
Starburst Contrôle d'accès intégré avec masquage de colonnes et filtrage de lignes Politiques OPA avec 8 masques prédéfinis
Cloudera Politiques Ranger avec contrôle d'accès basé sur les tags Couches de données OPA avec tags limités au projet

Consensus de l'industrie

L'industrie de la gouvernance des données a convergé vers plusieurs bonnes pratiques qu'AKKO implémente :

Bonne pratique Implémentation AKKO
Évaluation de politique à l'exécution (pas de pré-provisionnement) OPA évalue les groupes JWT au moment de la requête
Séparation de l'identité et de l'autorisation Keycloak (identité) + OPA (autorisation)
Comptes de service pour l'automatisation Keycloak client_credentials + Secrets K8s
Masquage de colonnes en objets réutilisables 8 masques prédéfinis, appliqués déclarativement
Sécurité au niveau des lignes par périmètre de données Filtres de lignes par projet, combinés en ET (AND)
Piste d'audit centralisée Toutes les décisions d'accès journalisées dans les logs de décision OPA

Différenciateur AKKO

Un seul JWT contrôle tous les services. Dans les plateformes concurrentes, chaque service possède son propre système de contrôle d'accès. Dans AKKO, un seul jeton JWT Keycloak porte le rôle plateforme, l'appartenance à l'équipe et le périmètre projet -- et chaque service le respecte :

                    Jeton JWT unique
                         |
        +----------------+------------------+
        |                |                  |
        v                v                  v
   +--------+     +-----------+     +-------------+
   | Trino  |     |   object storage   |     | JupyterHub  |
   |  OPA   |     | Éval. JWT |     | Env spawner |
   +--------+     +-----------+     +-------------+
        |                |                  |
        v                v                  v
   +--------+     +-----------+     +-------------+
   |LiteLLM |     |   Spark   |     |  OpenMeta   |
   |Clé API |     |  Submit   |     |  Domaine    |
   |par rôle |     | en svc    |     |  visibilité |
   +--------+     +-----------+     +-------------+

Aucune autre plateforme open-source n'atteint ce niveau de gouvernance inter-services avec un seul jeton d'identité.

Résumé

Dimension Source Claim JWT Contrôle
Rôle plateforme Rôle realm Keycloak groups: ["akko-analyst"] Accès outils, niveau ressources, accès modèles IA
Équipe métier Groupe directory service groups: ["equipe-marketing"] Stockage d'équipe partagé dans object storage
Projet Groupe directory service groups: ["projet-scoring"] Accès données (schémas, tables, lignes, colonnes)
Composant Rôle dans la gouvernance
Keycloak Fournisseur d'identité, émetteur JWT, gestionnaire de comptes de service
directory service Gestion des groupes (équipes et projets)
OPA Moteur de politique (autorisation, masquage, filtrage)
object storage Stockage avec évaluation de politique JWT à l'exécution
Trino Moteur de requêtes avec contrôle d'accès délégué à OPA
OpenMetadata Catalogue de données avec visibilité par domaine
Cockpit Interface d'administration pour la gestion des projets/masques/filtres

Documentation connexe