Technical Tutorials

Dans le paysage en évolution rapide du déploiement local de grands modèles de langage (LLM), Open WebUI s'est imposé comme l'interface de référence pour interagir avec les modèles exécutés sur du matériel local. Cependant, à mesure que les organisations passent de l'expérimentation individuelle à des environnements de cluster partagés, la sécurité et le contrôle d'accès deviennent essentiels. Cet article explore comment implémenter un contrôle d'accès basé sur les rôles (RBAC) multi-locataires robuste dans Open WebUI pour garantir que les clusters LLM locaux partagés restent sécurisés, efficaces et conformes.

Comprendre le défi multi-locataire dans les clusters locaux

Lors du déploiement de LLM en local, en particulier dans des clusters gourmands en ressources utilisant des technologies comme Ollama ou llama.cpp, plusieurs équipes ou utilisateurs ont souvent besoin d'accéder aux mêmes modèles backend. Sans une isolation appropriée, cette configuration peut entraîner des risques de sécurité importants, y compris l'accès non autorisé aux données, les attaques par injection de prompts et la concurrence pour les ressources. La multi-locataire permet à des groupes distincts (locataires) de partager la même infrastructure sous-jacente tout en maintenant une séparation logique des données et des autorisations.

Open WebUI, bien que puissant, n'applique pas nativement de frontières strictes entre les locataires dans les configurations d'entreprise complexes. Par conséquent, les architectes doivent configurer la plateforme et l'infrastructure environnante pour prendre en charge efficacement le RBAC.

Stratégie architecturale : Isolation et gestion de l'identité

La stratégie centrale implique trois couches : l'authentification de l'identité, la définition des rôles et les politiques d'accès aux ressources.

Authentification de l'identité : Intégrez Open WebUI avec un fournisseur d'identité (IdP) externe tel que LDAP, SAML ou OpenID Connect (OIDC). Cela garantit que les identités des utilisateurs sont gérées et vérifiées de manière centralisée.
Définition des rôles : Définissez des rôles granulaires au sein de votre organisation. Par exemple :
- Administrateur : Accès complet à la gestion des modèles et à l'administration des utilisateurs.
- Développeur : Accès pour créer et tester des modèles, consulter les journaux.
- Utilisateur final : Accès uniquement aux modèles pré-approuvés et à l'historique de discussion.
Politiques d'accès aux ressources : Associez les rôles à des modèles ou des groupes de modèles spécifiques. Cela empêche, par exemple, un utilisateur final général d'accéder à un modèle interne sensible fine-tuné.

Implémentation : Configuration d'Open WebUI avec OIDC

Ci-dessous, un exemple pratique de la configuration d'Open WebUI pour utiliser un IdP externe via des variables d'environnement lors du déploiement avec Docker ou Kubernetes. C'est la première étape pour appliquer le RBAC, car elle permet à votre IdP d'injecter les groupes et les rôles d'utilisateur dans le jeton JWT.


docker run -d -p 3000:8080 \
  -v open-webui:/app/backend/data \
  -e OPEN_WEBUI_AUTH_REGISTRATION=False \
  -e OPEN_WEBUI_USE_OAUTH=True \
  -e OPEN_WEBUI_OAUTH_CLIENT_ID="your-client-id" \
  -e OPEN_WEBUI_OAUTH_CLIENT_SECRET="your-client-secret" \
  -e OPEN_WEBUI_OAUTH_AUTHORIZATION_URL="https://idp.example.com/auth" \
  -e OPEN_WEBUI_OAUTH_TOKEN_URL="https://idp.example.com/token" \
  -e OPEN_WEBUI_OAUTH_USERINFO_URL="https://idp.example.com/userinfo" \
  -e OPEN_WEBUI_ALLOWED_OAUTH_ROLES="admin,developer,user" \
  open-webui/open-webui:main

Dans cette configuration, la variable OPEN_WEBUI_ALLOWED_OAUTH_ROLES agit comme un gardien. Si le jeton JWT fourni par l'IdP ne contient pas l'un des rôles listés, l'accès est refusé. C'est la fondation du RBAC.

Application du contrôle d'accès au niveau des modèles

Une fois les utilisateurs authentifiés et assignés à des rôles, vous devez vous assurer qu'ils ne peuvent interagir qu'avec les modèles autorisés. Open WebUI permet des scripts personnalisés et des extensions middleware. Pour les configurations avancées, vous pouvez implémenter un middleware personnalisé dans votre backend LLM (par exemple, un proxy Ollama personnalisé) qui inspecte le jeton JWT avant de servir la réponse du modèle.

Voici un exemple de pseudo-code d'une vérification middleware dans un proxy basé sur Python :


from functools import wraps
from fastapi import Depends, HTTPException
import jwt

def require_role(role: str):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            token = get_current_token()  # Extract from request header
            try:
                payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
                if role not in payload.get("roles", []):
                    raise HTTPException(status_code=403, detail="Insufficient permissions")
            except jwt.ExpiredSignatureError:
                raise HTTPException(status_code=401, detail="Token expired")
            except jwt.InvalidTokenError:
                raise HTTPException(status_code=401, detail="Invalid token")
            return func(*args, **kwargs)
        return wrapper
    return decorator

@app.get("/models/{model_id}/chat")
@require_role("developer")
async def chat(model_id: str):
    # Only developers can access this specific model
    return await llm_service.generate(model_id)

Meilleures pratiques pour les clusters partagés sécurisés

Audit régulier : Activez la journalisation dans Open WebUI et transmettez les journaux à un outil SIEM. Surveillez les schémas d'accès anormaux, tels qu'un rôle "utilisateur" tentant d'accéder à un point de terminaison "administrateur".
Segmentation du réseau : Placez l'instance Open WebUI et le backend LLM dans des segments de réseau distincts. Utilisez des pare-feu pour restreindre l'accès direct à l'API LLM, en veillant à ce que tout le trafic passe par le proxy Open WebUI où les vérifications RBAC sont effectuées.
Gestion des secrets : Utilisez un gestionnaire de secrets comme HashiCorp Vault ou Kubernetes Secrets pour stocker les clés API et les secrets JWT. Ne codez jamais les secrets en dur dans les fichiers de configuration.
Principe du moindre privilège : Attribuez le rôle le plus bas possible à chaque utilisateur. Examinez régulièrement les affectations de rôles pour supprimer l'accès des employés ayant changé de rôle ou quitté l'organisation.

Conclusion

L'implémentation du RBAC multi-locataire dans Open WebUI pour les clusters LLM locaux partagés est essentielle pour les déploiements de niveau entreprise. En intégrant des IdP externes, en définissant des rôles granulaires et en appliquant des contrôles d'accès au niveau des modèles, vous pouvez créer un environnement sécurisé et évolutif. Cette approche protège non seulement les données et les modèles sensibles, mais garantit également la conformité aux réglementations de sécurité internes et externes. À mesure que l'adoption de l'IA locale augmente, l'investissement dans des mécanismes de contrôle d'accès robustes sera un facteur clé de différenciation pour les organisations cherchant à exploiter le pouvoir des LLM en toute sécurité et efficacement.