Aller au contenu principal

D-14 Passerelle API

Brique D: Outils, skills, plugins, MCP, connecteurs. Version anglaise: D-14-api-gateway

1. Rôle et responsabilités​

Point d'entrée nord-sud : TLS, authentification, limitation de débit, routage vers le Control Plane et les passerelles.

  • Terminaison TLS et mTLS
  • Validation JWT Keycloak / clés API
  • Limite de débit par tenant et par clé
  • Propagation de traceparent et X-Request-Id

2. Position dans l'architecture et interactions​

  • Appelants: Tous les clients externes.
  • Chemin d'exécution: Synchrone.
  • Toute interaction passe par l'API Control Plane v1 (/v1) derrière la passerelle API (D-14).

3. Composant open source et partie développée​

  • Open source: Apache APISIX / Envoy
  • Développé: Configuration déclarative et plugins d'auth.
  • Intégration externe via un adaptateur eai/integrations/<system>.py avec repli in-process lorsque l'URL n'est pas configurée.

4. Modèle de données​

Tables (schéma eai, RLS tenant_id):

  • eai.api_keys (lecture)

Colonnes communes : id uuid, tenant_id uuid NOT NULL, created_at, updated_at ; politique RLS current_setting('app.tenant_id', true)::uuid.

5. Contrat​

  • Contrat appliqué: aucun manifeste ; règles transverses de l'API v1
  • Champs clés: Authorization, X-API-Key, X-Project, X-Environment, Idempotency-Key
  • Validation : POST /v1/contracts/{name}/validate ; application d'un manifeste : POST /v1/manifests/apply.

6. Endpoints API​

  • GET /healthz
  • GET /readyz
  • GET /v1/meta

Requête GET /v1/meta:

{}

Réponse:

{
"version": "1.0.0",
"features": [
"agents",
"tools",
"rag"
],
"locales": [
"en",
"fr"
]
}

7. Exemples SDK​

Python:

from enterprise_ai import EnterpriseAI

client = EnterpriseAI(base_url="<control-plane-url>", api_key="eai_xxx_secret")
meta = client.system.meta()

TypeScript:

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

const client = new EnterpriseAI({ baseUrl: "<control-plane-url>", apiKey: process.env.EAI_API_KEY });
const meta = await client.meta.get();

Java:

EnterpriseAIClient client = EnterpriseAIClient.builder()
.baseUrl("<control-plane-url>")
.apiKey(System.getenv("EAI_API_KEY"))
.build();
JsonNode meta = client.meta().get();

Go:

c, _ := eai.NewClient(eai.WithBaseURL("<control-plane-url>"), eai.WithAPIKey(os.Getenv("EAI_API_KEY")))
meta, _ := c.Meta(ctx)

8. Configuration​

  • Variables d'environnement: EAI_DATABASE_URL
  • Clés Helm: global.namespaces

9. Contrôles de sécurité​

  • WAF et limites de taille
  • Tenant résolu depuis le credential, jamais depuis le corps
  • Toutes les requêtes portent le tenant issu du credential ; RLS PostgreSQL
  • Chaque mutation et décision de politique écrit un événement d'audit chaîné

10. Observabilité​

  • Métriques Prometheus: apisix_http_status, envoy_http_downstream_rq_total
  • Traces: spans OpenTelemetry avec conventions sémantiques GenAI (gen_ai.operation.name, gen_ai.agent.id, gen_ai.tool.name), attributs eai.tenant_id, eai.run_id, propagation traceparent.
  • Actions d'audit : aucune action dédiée ; les refus d'APISIX (authentification, limite de débit) sont journalisés par APISIX et les appels acceptés produisent les actions du domaine appelé, par exemple model.invoke.

11. Unités FinOps​

  • Requêtes API.
  • Émis comme Usage Event (POST /v1/finops/usage) avec tenant, projet, agent et run.

12. Modes de défaillance et résilience​

  • Contrôles de santé actifs ; nouvelle tentative sur 503 uniquement pour GET
  • Erreurs normalisées (enveloppe error, message_i18n en/fr)

13. Adoption autonome (client d'un client)​

  • Peut être placée devant n'importe quelle brique ; Helm apiGateway.enabled.
  • SDK: enterprise_ai.tools / mcp / skills / plugins / connectors / channels
  • Déploiement minimal : chart Helm avec controlPlane.enabled=true et PostgreSQL ; les composants externes désactivés utilisent leur repli in-process.

14. Tests d'acceptation​

  1. Sans credential -> 401
  2. Dépassement de la limite de débit -> 429
  3. Accès inter-tenant refusé
  4. Erreur renvoyée en fr avec Accept-Language: fr

Preuve kit L3​

Validation hors ligne : tests/test_apisix_config_schema.py vérifie deploy/apisix/apisix.yaml contre les schémas d'objets et de plugins d'APISIX 3.x (limit-count, ip-restriction, request-id, openid-connect, limit-req) et la politique d'entrée (authentification, limitation de débit, identifiant de requête sur chaque route /v1, restriction IP des routes de santé). Démarrer APISIX demande root ou Docker, indisponibles sur l'hôte de test. Sortie : tests/test_security_egress.py, tests/test_security_egress_wiring.py.