Passerelle LiteLLM : cinq accès à fermer en priorité

Pour sécuriser une passerelle LiteLLM, fermez cinq accès en priorité : l’entrée réseau, les privilèges d’administration, les secrets accessibles au processus, la consommation sans limite et les angles morts de la journalisation. L’objectif est de réduire à la fois la probabilité d’une intrusion et ce qu’une clé, un compte ou une charge de travail compromis permettrait d’atteindre.

Avant la production, associez chaque frontière à une preuve : accès direct refusé, clé virtuelle restreinte, secret hors de portée, plafond de consommation appliqué et événement de sécurité visible. La passerelle devient ainsi un point de contrôle entre les applications et les fournisseurs de modèles, sans devenir un passage illimité vers leurs identifiants ou le reste de l’infrastructure.

1. Fermer l’entrée réseau et isoler l’administration

Passerelle LiteLLM isolée derrière un frontal protégé, avec refus des accès directs au conteneur, à l’administration et à la base.

Ne publiez pas directement le port du proxy LiteLLM. Placez l’API derrière un frontal TLS contrôlé, puis limitez les connexions à l’origine aux seuls composants autorisés. L’interface d’administration, la base de données et les services de cache ne doivent pas partager la même exposition que l’API appelée par les applications.

Dans l’architecture de référence d’AWS, les clients passent par CloudFront et AWS WAF avant l’équilibreur de charge, tandis que les conteneurs LiteLLM s’exécutent sur ECS ou EKS ; Secrets Manager conserve les identifiants de fournisseurs et S3 centralise les journaux applicatifs. Ces services précis ne sont pas indispensables, mais leur découpage fournit un modèle vérifiable : un point d’entrée public, des charges isolées et des dépendances internes non exposées.

N’autorisez que les routes et méthodes nécessaires. Appliquez en amont des limites de débit et, lorsque l’API doit rester publique, un filtrage des requêtes anormales. Si seuls des services internes utilisent la passerelle, préférez une adresse privée et une connectivité interservices authentifiée.

Validation : depuis un réseau non autorisé, vérifiez que le port du conteneur, l’administration et la base sont injoignables. Seul le frontal doit répondre en TLS, et une requête sans authentification doit être rejetée avant tout appel à un fournisseur.

2. Fermer l’administration avec des clés virtuelles

La clé maîtresse ne doit pas devenir l’identifiant commun des applications. Réservez-la aux opérations administratives dans un périmètre restreint, puis attribuez une clé virtuelle distincte à chaque service, environnement ou équipe. Vous pourrez ainsi révoquer un accès compromis sans interrompre tous les consommateurs.

La documentation officielle de LiteLLM décrit le Proxy Server comme une passerelle centralisée proposant authentification, autorisation, clés virtuelles, suivi des coûts, gestion des dépenses par projet ou utilisateur et limitation du débit. Utilisez cette granularité pour rattacher chaque clé à un propriétaire, aux seuls modèles nécessaires, à une durée de validité adaptée et à des limites cohérentes avec sa charge.

N’intégrez ni clé maîtresse ni identifiant de fournisseur dans un navigateur, une application mobile, un dépôt ou une image de conteneur. Séparez également les identités humaines des identités de service. L’accès d’administration doit employer un mécanisme plus strict que celui des appels ordinaires et rester inaccessible aux clés applicatives.

Validation : une clé de test doit échouer sur une route administrative et sur un modèle absent de sa politique. Après révocation, elle doit être refusée sans affecter les autres applications.

3. Fermer l’accès du processus aux secrets latéraux

Identité d’exécution LiteLLM limitée aux secrets des fournisseurs, sans accès aux clés SSH, aux jetons CI/CD ni aux privilèges Kubernetes.

Un coffre central ne protège pas un secret que l’identité d’exécution peut librement lire. Autorisez la charge LiteLLM à récupérer uniquement les identifiants de fournisseurs dont elle a besoin, sans droit général de lister ou de modifier le coffre. Évitez les fichiers .env persistants et les secrets incorporés dans les couches de l’image.

Retirez aussi de son environnement les clés SSH, jetons de publication, secrets CI/CD, configurations Docker et jetons de compte de service Kubernetes qui ne servent pas à la passerelle. Donnez-lui une identité de base de données dédiée, limitée aux opérations nécessaires, et évitez tout montage offrant un contrôle sur l’hôte ou sur d’autres conteneurs.

Cette séparation répond à un scénario documenté : l’enquête de Datadog Security Labs établit que les versions PyPI 1.82.7 et 1.82.8 de LiteLLM, publiées le 24 mars 2026 avec du code malveillant, collectaient notamment variables d’environnement, clés SSH, identifiants cloud, données Kubernetes, configurations Docker, secrets CI/CD et identifiants de bases. Le logiciel pouvait également installer une persistance et créer des pods privilégiés lorsqu’un jeton Kubernetes exploitable était accessible.

Si l’une de ces versions a été installée, ne vous contentez pas de remplacer le paquet. Délimitez les hôtes, conteneurs et tâches CI concernés ; révoquez tout identifiant que leur processus pouvait lire ou récupérer ; recherchez ensuite la persistance et les actions Kubernetes. Reconstruisez les charges critiques depuis des images de confiance avec des dépendances épinglées.

Validation : créez un secret sentinelle auquel LiteLLM ne doit pas accéder et confirmez le refus avec son identité d’exécution. Inspectez ensuite l’image, les volumes, les variables et le compte Kubernetes pour vérifier qu’aucun accès latéral inutile ne subsiste.

4. Fermer la consommation illimitée des fournisseurs

Une requête authentifiée ne doit pas ouvrir une capacité de dépense sans plafond. Affectez un budget et une limite de débit à chaque clé virtuelle, projet ou équipe, puis réservez les modèles les plus coûteux aux consommateurs qui en ont réellement besoin. Les seuils doivent provenir d’un profil de charge observé, avec une marge explicite pour les pointes normales.

Cloisonnez aussi les identifiants chez chaque fournisseur. Lorsque ses contrôles le permettent, utilisez un compte de service dédié et séparez production, développement et expérimentation. La clé remise à LiteLLM ne devrait autoriser que les API de modèles requises, sans droits sur le stockage, le déploiement, la gestion des identités ou la facturation générale.

Limitez enfin les sorties réseau de la charge aux fournisseurs configurés, au coffre, à la base et aux services de télémétrie nécessaires. Documentez les dépendances DNS et de certificats avant d’activer ce filtrage afin qu’un mécanisme de sécurité ne provoque pas une panne difficile à diagnostiquer.

Validation : utilisez une clé de test dotée d’un plafond faible et confirmez que les appels sont refusés une fois la limite atteinte. Vérifiez séparément qu’un fournisseur ou un modèle non autorisé reste inaccessible et que l’identifiant sous-jacent n’apparaît jamais dans l’erreur.

5. Fermer l’angle mort des journaux et de la rotation

Événements LiteLLM attribués dans la supervision après un refus, une révocation et un dépassement de budget, avec données sensibles masquées.

Journalisez les décisions de sécurité sans enregistrer les secrets. Conservez les échecs d’authentification, créations et révocations de clés, changements de droits, appels par identité, modèles demandés, consommations, dépassements et opérations administratives. Protégez ces événements contre la modification et retenez-les assez longtemps pour votre procédure d’enquête.

Les invites et réponses pouvant contenir des données sensibles, ne les conservez pas intégralement par défaut. Désactivez le débogage détaillé en production, masquez les en-têtes d’autorisation et les champs secrets, puis testez la rédaction avec des valeurs sentinelles. L’accès aux journaux doit lui-même respecter le moindre privilège.

Préparez avant l’incident l’ordre de révocation selon la portée réelle : clé maîtresse, clés virtuelles, identifiants de fournisseurs, accès à la base, identités cloud ou Kubernetes, puis jetons CI/CD et de publication accessibles depuis l’environnement. Un redémarrage ou un changement de version ne révoque pas un identifiant déjà copié.

Validation finale : provoquez un échec d’authentification, révoquez une clé de test et atteignez un plafond de consommation contrôlé. Les trois événements doivent être horodatés, attribuables et visibles dans la supervision, sans clé ni contenu sensible en clair.

Sécuriser une passerelle LiteLLM : cinq accès à fermer en priorité