Contrôle RBAC des fonctions IA¶

AKKO fournit 25 fonctions scalaires Trino (20 d'analyse : ai_sentiment, ai_pii, ai_embed, ai_parse_document, ai_ocr, ai_transcribe, ai_search, etc. + 5 helpers admin : ai_health, ai_stats, ai_version, ai_cache_clear, ai_cb_reset) qui délèguent les appels au service IA. Comme l'autorisateur OPA natif de Trino ne déclenche pas ExecuteFunction pour les UDF scalaires fournies par un plugin, le RBAC est appliqué dans le middleware du service IA, pas directement dans OPA.

Flux d'application¶

Requête Trino : SELECT ai_sentiment('hello') FROM ...
   │
   ▼
Plugin Trino (trino-ai-functions) transmet :
   Authorization: Bearer ${AKKO_AI_SERVICE_TOKEN}
   X-Trino-User: <appelant>
   X-Akko-Ai-Function: ai_sentiment
   │
   ▼
Middleware AI Service (docker/ai-service/app.py) :
   1. Vérifie le Bearer token contre le Secret akko-trino-ai
   2. Résout le rôle realm de l'appelant via l'API admin Keycloak (cache 300 s)
   3. Vérifie la matrice RBAC : ai_sentiment est-il autorisé pour ce rôle ?
   4. AUTORISE → exécution + métriques + journal d'audit
      REFUSE   → renvoie 403 + métriques + journal d'audit

Matrice RBAC (20 fonctions d'analyse + 5 helpers admin)¶

Fonction	akko-admin	akko-engineer	akko-analyst	akko-steward	akko-viewer
`ai_sentiment`	✓	✓	✓	✗	✗
`ai_classify`	✓	✓	✓	✗	✗
`ai_summarize`	✓	✓	✓	✗	✗
`ai_translate`	✓	✓	✗	✗	✗
`ai_entities`	✓	✓	✗	✗	✗
`ai_anomaly`	✓	✓	✗	✗	✗
`ai_sql`	✓	✓	✗	✗	✗
`ai_risk`	✓	✓	✗	✗	✗
`ai_pii`	✓	✓	✗	✓	✗
`ai_sensitivity`	✓	✓	✗	✓	✗
`ai_language`	✓	✓	✓	✗	✗
`ai_keywords`	✓	✓	✓	✗	✗
`ai_ask`	✓	✓	✗	✗	✗
`ai_embed`	✓	✓	✗	✗	✗
`ai_parse_document`	✓	✓	✓	✗	✗
`ai_transcribe`	✓	✓	✓	✗	✗
`ai_describe_image`	✓	✓	✓	✗	✗
`ai_ocr`	✓	✓	✓	✗	✗
`ai_cache_clear` (admin)	✓	✗	✗	✗	✗
`ai_cb_reset` (admin)	✓	✗	✗	✗	✗
`ai_stats`	✓	✓	✗	✗	✗

Les viewers n'ont accès à aucune fonction IA — tout appel renvoie HTTP 403.

Activation¶

L'application est conditionnée par deux valeurs Helm. Les deux sont à false par défaut pour la commodité en dev ; les déploiements production DOIVENT les passer à true.

akko-ai-service:
  serviceToken:
    enabled: true        # Le plugin Trino doit présenter un Bearer token partagé
    secretName: akko-trino-ai
    secretKey: service-token
  rbac:
    enabled: true
    keycloakUrl: "http://akko-akko-keycloak:8080"
    keycloakRealm: akko
    userRoleCacheTtlSeconds: 300

Le Secret akko-trino-ai est auto-généré par helm/akko/templates/secrets.yaml et réutilisé à chaque upgrade via lookup. Le même token est injecté dans le déploiement Trino sous forme de AKKO_AI_SERVICE_TOKEN pour que le plugin puisse s'authentifier.

Tests¶

# En tant que viewer (dave) → 403 attendu
kubectl exec -n akko svc/akko-trino -- \
  trino --user dave --execute "SELECT ai_sentiment('test')"
# Erreur : Access Denied — rôle 'akko-viewer' non autorisé pour 'ai_sentiment'

# En tant qu'analyst (carol) → succès attendu
kubectl exec -n akko svc/akko-trino -- \
  trino --user carol --execute "SELECT ai_sentiment('test')"
# => POSITIVE

# Fonction admin → viewer refusé
kubectl exec -n akko svc/akko-trino -- \
  trino --user alice --execute "SELECT ai_cache_clear()"
# => OK
kubectl exec -n akko svc/akko-trino -- \
  trino --user bob --execute "SELECT ai_cache_clear()"
# Erreur : fonction réservée aux administrateurs

Test E2E Playwright : tests/playwright/rbac-ai-functions.spec.ts vérifie l'intégralité de la matrice contre un cluster live.

Observabilité¶

Compteurs Prometheus (exposés par le service IA /metrics) :

akko_ai_rbac_allowed_total{function,role}
akko_ai_rbac_denied_total{reason,function,role}

Journal d'audit (JSON structuré sur stdout → logs layer/logs layer) :

{
  "audit_type": "AI_RBAC",
  "decision": "DENY",
  "user": "dave",
  "role": "akko-viewer",
  "function": "ai_sentiment",
  "reason": "role_not_permitted",
  "timestamp": "2026-04-19T14:22:07Z"
}

Dépannage¶

Symptôme	Cause probable	Correctif
Tous les appels réussissent pour un viewer	`rbac.enabled=false` ou `serviceToken.enabled=false`	Basculer les deux à `true` dans `values-<env>.yaml` puis `helm upgrade`
Tous les appels renvoient 401	Secret `akko-trino-ai` absent ou Trino ne le lit pas	Vérifier `kubectl describe deploy/akko-trino-coordinator` pour la variable `AKKO_AI_SERVICE_TOKEN`
Tous les appels renvoient 403 même pour les rôles valides	Creds admin Keycloak invalides → fallback sur `default_role`	Consulter les logs du service IA pour `kc_admin_login_failed`, puis rotation des creds
Journal d'audit vide	logs layer (ou logs layer) ne collecte pas stdout	Vérifier que promtail/vector cible bien les pods du service IA