LiteLLM allowed_routes ist Enterprise-only: mein robuster Workaround

Wer ein eigenes LLM-Gateway betreibt (bei mir LiteLLM als zentraler Proxy vor einem Dutzend Modell-Providern), kennt das Grundprinzip: Ein Gateway bündelt Routing, Tier-Logik, Budgets und Kostenschutz an einer Stelle. Genau dieses Bündeln hat aber eine Achillesferse — die Provider-Pass-Through-Routen (/anthropic/, /vertex_ai/, /gemini/). Über die reicht das Gateway Requests roh zum Original-Provider durch. Heißt: Wer sie erreicht, umgeht Classifier, Tier-Routing und* Budget — und ruft direkt das teuerste Modell ab.

Die naheliegende Verteidigung in LiteLLM ist eine Route-Allowlist: allowed_routes — nur explizit gelistete Pfade sind erreichbar, alles andere → 403. Klingt nach Basishygiene. Ist es auch. Und genau deshalb hat es mich überrascht, dass es ein Enterprise-Feature ist. Die Doku ist eindeutig: „Requires a LiteLLM Enterprise License … Without a license, this functionality is not available."

Ein Route-Allowlisting hinter eine kostenpflichtige Lizenz zu legen, ist eine bemerkenswerte Designentscheidung — denn es ist nicht „nice to have", sondern verhindert eine konkrete Budget-Umgehung. Open-Core-Projekte finanzieren sich über solches Feature-Gating (SSO, RBAC, Audit-Logs sind klassische Kandidaten), das ist legitim. Aber eine simple Egress-Allowlist fühlt sich in dieser Liste fehl am Platz an.

Kurioses Detail aus meinen Tests (Version 1.82.3): Gesetzt habe ich allowed_routes trotzdem — und es hat die Pass-Through-Routen tatsächlich mit 403 geblockt, obwohl unlizenziert. Der Preis: eine „Enterprise feature"-Warnung im Log bei jedem Request (mehrere Tausend Zeilen pro Tag), und laut Doku ist das Verhalten unsupported. Andere, nicht gelistete Routen blieben gleichzeitig offen. Übersetzung: Verlass dich nicht darauf. Unlizenziert ist es ein undokumentierter Zufallszustand, der mit dem nächsten Update kippen kann.

Der robuste Workaround: erzwinge Route-Restriction dort, wo du sie zu 100 % besitzt

Nicht im Gateway, sondern in den Schichten darum herum:

Gateway nicht offen exponieren. Bind auf [server] bzw. nur ins interne Container-Netz. Kein Host-Port, kein öffentlicher Reverse-Proxy direkt auf den Gateway-Port. Allein das nimmt einen Großteil der Angriffsfläche.

Pass-Throughs hart abschalten: pass_through_endpoints: [] in den general_settings. (Reicht allein nicht gegen alle Routen — aber gehört dazu.)

Allowlist am Reverse Proxy. Wer das Gateway doch von außen erreichbar macht, lässt in nginx nur die nötigen Pfade durch, der Rest → 403:

# Nur produktive API-Pfade durchlassen, alles andere blocken
location ~ ^/(v1/chat/completions|v1/embeddings|v1/models|health)$ {
    proxy_pass http://litellm_upstream;
}
location / { return 403; }

Das wirkt lizenzunabhängig, versionsstabil und ist auditierbar — du siehst die Regel in deiner eigenen Config, nicht in einer fremden Feature-Flag-Logik.

Defense in Depth im Gateway: Pro Client einen eigenen Key mit Model-Allowlist und Tagesbudget. Selbst wenn jemand eine Route erreicht, kann er kein Modell außerhalb seiner Erlaubnis und kein Budget jenseits des Limits ziehen.

Fazit

Dass ein Basis-Sicherheitsfeature als Enterprise markiert ist, kann man kritisieren — aber die eigentliche Lehre ist eine generelle: Sicherheit gehört in die Schicht, die dir gehört. Ein fremdes Feature-Flag (das morgen anders funktioniert) ist ein schlechterer Ankerpunkt als zwölf Zeilen nginx, die du selbst kontrollierst.

Quellen: LiteLLM — Control Public & Private Routes, LiteLLM — Enterprise Features