Aller au contenu principal

A05 - Autorisations

GroupeTechnologieStatutServicePhase de la feuille de routeContrats
A - Gouvernance, identité et sécuritéOpenFGAopen source intégréauthz1-

Retour à l'index - English

Rôle et responsabilités​

Autorisations fines par relations (ReBAC) sur tenants, projets, agents, outils, bases de connaissances.

Modèle de données​

Tables (schéma eai, chaque table tenant porte tenant_id uuid NOT NULL avec une politique RLS sur current_setting('app.tenant_id', true)::uuid) : eai.authz_tuples, eai.audit_events.

Endpoints API​

  • POST /v1/authz/check
  • POST /v1/authz/tuples
  • DELETE /v1/authz/tuples
POST /v1/authz/check HTTP/1.1
Host: <control-plane-host>
X-API-Key: eai_xxx_secret
Accept-Language: fr
Content-Type: application/json

{"subject": "user:alice", "relation": "can_run", "object": "agent:support-bot"}
{"allowed": true, "backend": "openfga"}

Les erreurs utilisent l'enveloppe commune {"error": {"code", "message", "message_i18n", "details", "request_id"}} ; les listes sont paginées avec limit et cursor.

Relations sur les ressources (ReBAC)​

Les routes des projets, agents, outils, bases de connaissances, serveurs MCP, skills et plugins dépendent de require_relation(relation, type, paramètre) : viewer pour lire, editor pour modifier, owner pour supprimer, can_invoke pour exécuter, invoquer, interroger ou relayer. Ordre de résolution : tuple direct sur la ressource (OpenFGA s'il est configuré, sinon eai.authz_tuples), puis le projet de rattachement (project:<id> project <type>:<id>, owner from project, viewer from project), puis le rôle dans le tenant. Les rôles de tenant gardent la portée de model.fga : tenant_admin est admin du tenant, donc owner de chaque projet et de ses ressources ; developer et security_officer sont editors du tenant ; les autres rôles en sont membres. Tout membre est viewer des projets (viewer from tenant). Une ressource sans projet hérite du tenant. La création écrit le tuple owner et, avec X-Project, le lien vers le projet. Un refus répond 403 relation_required (EN et FR) et est audité authz.deny. Les contrôles de rôle existants s'appliquent en plus de la relation.

Utilisation des SDK​

Python (enterprise_ai):

from enterprise_ai import EnterpriseAI

client = EnterpriseAI(base_url="<control-plane-url>", api_key="eai_xxx_secret")
decision = client.identity.check(subject="user:alice", relation="viewer", object="project:p1")

TypeScript (@enterprise-ai/sdk):

import { EnterpriseAI } from "@enterprise-ai/sdk";

const eai = new EnterpriseAI({ baseUrl: "<control-plane-url>", apiKey: process.env.EAI_API_KEY });
const decision = await eai.authz.check({ subject: "user:alice", relation: "viewer", object: "project:p1" });

Java (enterprise-ai-java):

EnterpriseAIClient client = EnterpriseAIClient.builder()
    .baseUrl("<control-plane-url>")
    .apiKey(System.getenv("EAI_API_KEY"))
    .build();
var decision = client.authz().check(Map.of("subject", "user:alice", "relation", "viewer", "object", "project:p1"));

Go (enterprise-ai-go):

client, _ := eai.NewClient(eai.WithBaseURL("<control-plane-url>"), eai.WithAPIKey(os.Getenv("EAI_API_KEY")))
decision, err := client.Authz.Check(ctx, map[string]any{"subject": "user:alice", "relation": "viewer", "object": "project:p1"})

Configuration​

  • Environnement : EAI_DATABASE_URL, EAI_OTEL_EXPORTER_OTLP_ENDPOINT.
  • Valeurs Helm : controlPlane.enabled, controlPlane.replicas, controlPlane.resources, controlPlane.config.

Contrôles de sécurité​

  • Authentification par JWT OIDC, clé API tenant avec scopes, ou mTLS SPIFFE ; le tenant est résolu depuis l'identifiant, jamais depuis le corps.
  • Autorisation par décisions OpenFGA et OPA ; chaque mutation et décision écrit une ligne eai.audit_events chaînée par hash.
  • Les secrets ne sont jamais renvoyés par l'API ; TLS partout ; les politiques réseau Cilium restreignent qui peut joindre le service.

Observabilité​

  • Métriques : eai_authorization_requests_total, eai_authorization_errors_total, eai_authorization_latency_seconds (Prometheus).
  • Traces : spans OpenTelemetry eai.authz.* avec propagation W3C traceparent, spans IA envoyés à Opik.
  • Actions d'audit : authz.check, authz.write, authz.delete, policy.evaluate.

Aspects FinOps​

Le coût d'exploitation est imputé par tenant et projet via les labels des Usage Events et les requêtes de ressources Kubernetes ; pas de coût direct par appel.

Modes de défaillance et résilience​

OpenFGA indisponible : le fallback intégré (tuples dans PostgreSQL) répond en dev ; en production les vérifications échouent fermées.

Adoption autonome (client d'un client)​

Un client d'un client peut adopter cette brique seule avec le sous-client SDK Python client.identity (TS eai.authz, Java client.authz(), Go client.Authz). Déploiement minimal : Control Plane API + PostgreSQL + Keycloak (ou clés API), le Control Plane charge tous les domaines de services/control-plane/src/eai/domains ; les composants optionnels du chart se coupent dans deploy/helm/enterprise-ai/values.yaml (vllm.enabled, qdrant.enabled, nats.enabled, workers.enabled).

Tests d'acceptation​

  1. Un tenant ne peut ni lire ni modifier les ressources d'un autre tenant (test RLS).
  2. Chaque mutation produit un événement d'audit vérifiable par GET /v1/audit/verify.
  3. Les erreurs sont renvoyées en anglais et en français selon Accept-Language.

Droits effectifs et délégations (kit 7 et 8)​

Chaque action d'agent est décidée par l'intersection utilisateur ET agent ET délégation ET ressource (contrôle de relation ci-dessus) ET politique : POST /v1/delegations/authorize rend la décision couche par couche, et une erreur du moteur de relations vaut refus. Une délégation (/v1/delegations) est toujours un sous-ensemble de sa parente et la révocation se propage. Voir identity-context-delegation.md. Tests : tests/test_identity_context_delegation.py.

Preuves sur composants réels​

Voir le guide du plan d'identité et de politiques : composants démarrés depuis les versions officielles (tools/iam/fetch.sh), tests services/control-plane/tests/test_iam_*.py.