Aller au contenu
Source

Qdrant — Security (API key, TLS, JWT avec claim payload)

C'est la seconde barrière recherchée : même si l'application est buguée, le moteur ne renvoie que les points autorisés par le JWT.

Confirmée#vector-db#qdrant#securite#permissionsPublié le 16 sept. 2026Mis à jour le 16 sept. 2026Vérifié le 16 sept. 2026À revérifier le 15 déc. 2026
Organisation
Qdrant
Type
Documentation officielle
Fiabilité
Fiabilité haute
Publié
lu le 16/09/2026 ; RBAC JWT introduit en 1.9.0 (blog du 24/04/2024)
Consulté le
16 septembre 2026
Sujets
vector-db, qdrant, securite, permissions

Citée par 4 page(s)

Ce que dit la source : clés API (lecture seule possible), TLS, et jetons JWT portant les claims access (r, m, rw), une restriction par collections et un claim payload (ex. "payload": {"tenant_id": "user_id"}) que le serveur applique comme filtre obligatoire sur les points. Le blog de release 1.9.0 (24/04/2024) présente cette fonctionnalité RBAC ; l'article « Data Privacy with Qdrant RBAC » la détaille.

Ce qu'on en retient : c'est la seconde barrière recherchée : même si l'application est buguée, le moteur ne renvoie que les points autorisés par le JWT.

Limites : contradiction avec la consigne interne « RBAC/JWT en 1.11+ » : le RBAC JWT date de 1.9.0 ; la 1.11 apporte is_tenant et les clés granulaires du cloud. Non tranché ici.

content/sources/qdrant-security.md124 mots