Ouvrir Open WebUI sur Internet sans reverse proxy ni HTTPS, c’est offrir une interface d’IA (et souvent ses documents) à des scanners automatiques. Ce tutoriel détaille une posture prudente pour une PME ou une collectivité des Hauts-de-France : risques, Caddy ou Nginx, certificats, authentification / SSO, pare-feu, sauvegardes, mises à jour. Prérequis : Linux de base, Docker, et une instance déjà utile en local ([[ta02|installation]], [[ta14|usage équipe]]).
Plan du tutoriel
Huit volets : risques, reverse proxy, HTTPS, SSO/auth, pare-feu, sauvegardes, mises à jour, checklist HdF. Complément recherche web : SearXNG. Chatbot public : widget site — encore plus exposé.
Risques si vous ouvrez trop vite
Interface d’admin découverte, brute force sur comptes faibles, exfiltration de bases knowledge, abus de votre GPU/CPU pour générer du contenu, rebond vers Ollama si le socket est mal isolé. Même une « petite » asso à Compiègne devient une cible opportuniste dès qu’un port répond. Le risque n’est pas théorique : les robots scannent en continu.
Accès interne seulement
VPN ou réseau bureau : surface réduite, souvent suffisant pour démarrer.
- Pas d’exposition Internet directe.
- Toujours HTTPS interne si possible.
- Comptes individuels quand même (équipe).
Accès Internet nécessaire
Télétravail, élus, bénévoles hors murs : proxy + auth + durcissement obligatoires.
- Jamais le port applicatif nu.
- SSO ou au minimum MFA si disponible.
- Journalisation et sauvegardes testées.
Reverse proxy : Caddy ou Nginx
Le reverse proxy termine TLS, route vers le conteneur Open WebUI sur le réseau Docker interne, et peut ajouter des en-têtes de sécurité. Caddy simplifie souvent l’obtention de certificats. Nginx est courant chez les prestataires. Choisissez ce que votre équipe saura relire à 3 h du matin.
# Principe pédagogique — adaptez images, versions et chemins via docs officielles
services:
openwebui:
image: ghcr.io/open-webui/open-webui:TAG
expose:
- "8080"
volumes:
- open-webui:/app/backend/data
networks: [internal]
caddy:
image: caddy:TAG
ports:
- "443:443"
- "80:80"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- caddy_data:/data
networks: [internal, edge]
networks:
internal:
edge:
volumes:
open-webui:
caddy_data:
# Caddyfile (principe)
# ia.exemple.fr {
# reverse_proxy openwebui:8080
# }HTTPS et certificats
Sans HTTPS, les identifiants et conversations circulent en clair sur les réseaux non maîtrisés. Utilisez un certificat valide (Let’s Encrypt via Caddy/Nginx, ou PKI interne). Redirigez HTTP vers HTTPS. Vérifiez la chaîne sur un téléphone en 4G, pas seulement depuis le bureau. Renouvez automatiquement ; surveillez l’échec de renouvellement.
Authentification et SSO
Six étapes avant ouverture extérieure
Décider du mode d’accès réel
VPN uniquement, Internet authentifié, ou hybride. Une collectivité près de Laon peut imposer le VPN agents pour l’admin et un SSO pour les utilisateurs métier. Documentez le choix. Si « Internet » n’est pas indispensable, ne l’ouvrez pas « au cas où ». La meilleure surface d’attaque est celle qui n’existe pas. Si le VPN suffit, documentez-le comme choix assumé : rouvrir Internet plus tard restera possible avec la checklist déjà prête. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Isoler Open WebUI derrière le proxy
Le conteneur n’écoute plus sur 0.0.0.0 public. Seul le proxy est publié. Coupez les ports obsolètes sur le pare-feu cloud ou la box. Vérifiez avec un scan externe autorisé (ou un simple contrôle depuis une IP hors réseau). Si le vieux port répond encore, vous n’avez rien sécurisé. Un scan externe autorisé après changement de pare-feu évite l’illusion de sécurité quand un ancien port traîne encore. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Forcer HTTPS et en-têtes de base
Activez la redirection, HSTS avec prudence (comprenez l’option avant), et des en-têtes raisonnables selon votre reverse proxy. Testez le certificat. Documentez le nom DNS officiel pour éviter les phishing internes « ia-securisee-pas-officielle.fr ». Publiez le nom DNS officiel dans la charte pour réduire les risques de liens d’hameçonnage internes maladroits. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Durcir l’authentification
Désactivez l’inscription ouverte. Imposez des mots de passe robustes ou branchez un SSO (OIDC/SAML selon ce que votre version et votre IdP supportent — lisez la doc Open WebUI du jour). Si MFA est disponible côté IdP, activez-la pour les admins au minimum. Révoquez les comptes de test. La MFA admin n’est pas négociable dès que l’instance quitte le réseau purement local de la collectivité ou de la PME. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Restreindre Ollama et services liés
Ollama, Qdrant, SearXNG ne doivent pas être joignables depuis Internet. Gardez-les sur un réseau Docker interne. Une API Ollama ouverte est un abonnement GPU gratuit pour le reste du monde. Vérifiez les publications de ports après chaque compose up. Ajoutez un test automatique simple qui échoue si Ollama répond depuis une adresse non interne. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Sauvegarder, restaurer, mettre à jour
Sauvegardez volumes de données et fichiers de config proxy. Testez une restauration sur machine de staging. Appliquez les mises à jour d’images après lecture des notes. Une instance jamais mise à jour derrière un beau HTTPS reste vulnérable applicativement. Planifiez un créneau mensuel. Le créneau mensuel de MAJ doit être annoncé à l’équipe métier : une IA indisponible sans préavis détruit l’adoption. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Pare-feu et exposition minimale
Autorisez 80/443 vers le proxy seulement. Admin SSH sur autre port ou bastion, idéalement clé + MFA. Si vos utilisateurs sont tous en Hauts-de-France sur IP stables, une allowlist peut réduire le bruit — sans remplacer l’auth. Surveillez les journaux d’accès pour les pics d’échec de login.
| Service | Internet | Commentaire |
|---|---|---|
| Reverse proxy (443) | Oui | Point d’entrée unique |
| Open WebUI | Non directement | Via proxy seulement |
| Ollama API | Non | Réseau interne |
| Qdrant | Non | Réseau interne |
| SearXNG | Non | Interne ; voir tutoriel |
| SSH | Restreint | Pas 22 ouvert au monde si évitable |
Sauvegardes et reprises
Une attaque ou une fausse manœuvre arrive. Sans sauvegarde testée, vous reconstruisez tout à la main. Incluez : volume Open WebUI, Caddyfile/Nginx, variables d’environnement hors secrets en clair dans le git, inventaire des tags d’images. Chiffrez les sauvegardes hors site selon votre politique.
Scène : cabinet à Lille et mairie
Un cabinet d’experts-comptables lillois expose Open WebUI aux collaborateurs en télétravail. Ils passent par Caddy + SSO Microsoft/Google selon leur IdP, VPN pour les admins, et interdisent les bases clients nominatives sur l’outil. Une mairie teste d’abord l’accès VPN uniquement ; l’ouverture Internet est reportée tant que le SSO n’est pas prêt. Les deux documentent le DNS officiel pour éviter les faux liens.
Checklist express
- Port applicatif non publié.
- HTTPS valide testé hors LAN.
- Inscription ouverte off.
- SSO ou mots de passe robustes + révocation.
- Ollama/Qdrant/SearXNG internes.
- Sauvegarde restaurée une fois avec succès.
- Procédure de MAJ datée.
Modèle de menaces minimal
Listez les profils d’attaquants plausibles et les parades déjà en place. Cet exercice court avec l’admin et un responsable métier évite les gadgets. Le trou fréquent reste un service annexe publié par erreur. Ajoutez le scénario sauvegarde illisible et testez la restauration comme un exercice périodique, pas seulement une case cochée sur un audit improvisé.
SSO : points de vigilance
Vérifiez le mapping des groupes, la déconnexion, et l’effet d’un compte désactivé dans l’annuaire. Testez avec un utilisateur hors IT. Un SSO mal câblé peut rendre tout le monde administrateur. Gardez un compte break-glass local, secret dans le coffre-fort d’équipe, pour survivre à une panne d’identité sans perdre l’accès d’urgence à l’instance.
Journaux et alertes
Surveillez au minimum les rafales d’échecs d’authentification sur le proxy et les redémarrages anormaux de conteneurs. Une alerte simple vers l’équipe IT suffit pour démarrer. Protégez les journaux : ils peuvent contenir des fragments utiles à un attaquant. Corrélez avec les fenêtres de maintenance pour limiter le bruit.
Exercice trimestriel de crise courte
Une fois par trimestre, jouez un scénario de soixante minutes : certificat expiré, IdP indisponible, ou volume corrompu. L’équipe doit restaurer depuis la sauvegarde ou activer le compte break-glass selon le cas. Chronométrez sans en faire un spectacle. Notez ce qui a manqué dans la documentation. Une collectivité près de Laon qui a déjà fait l’exercice réagit calmement ; celle qui découvre la procédure le jour J improvise dangereusement.
Enchaînez avec une question simple : qui a le droit de republier le port applicatif pour un test ? La bonne réponse est personne, sauf fenêtre de maintenance écrite. Cet exercice culturel complète les réglages techniques mieux qu’un long document jamais relu. Archivez le compte rendu de l’exercice avec la date et les participants, comme vous le feriez pour un exercice d’évacuation incendie.
Si l’exercice révèle qu’aucun membre présent ne sait relancer Caddy ou Nginx, planifiez immédiatement une formation courte à deux, puis un second exercice le mois suivant. La sécurité documentée sans compétence humaine disponible reste théorique. En Hauts-de-France, les petites équipes IT partagées entre plusieurs sites ont tout intérêt à doubler les savoir-faire plutôt qu’à concentrer les secrets sur une seule tête.
Questions fréquentes
Caddy est-il « plus sûr » que Nginx ?
La sécurité dépend surtout de la configuration, des mises à jour et de l’auth. Caddy rend le TLS souvent plus simple ; Nginx est très répandu. Choisissez l’outil que vous saurez maintenir. Un proxy mal relus reste un risque, quelle que soit la marque. Lisez les guides officiels actuels. Maintenabilité humaine bat les benchmarks marketing : choisissez l’outil que deux personnes savent dépanner. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Le VPN suffit-il sans HTTPS interne ?
Le VPN réduit la surface Internet, mais à l’intérieur du tunnel des pratiques saines restent utiles (comptes individuels, moindre privilège). HTTPS interne évite certains scénarios sur des réseaux plats. Ne prenez pas le VPN pour une absolution : une machine compromise sur le VPN voit encore votre IA. Un VPN n’autorise pas les comptes partagés ni les bases knowledge fourre-tout : le moindre privilège reste de mise. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Que faire des webhooks et APIs Open WebUI ?
Traitez-les comme des secrets. Ne les placez pas dans un front public. Régénérez en cas de fuite. Limitez les scopes si l’outil le permet. Documentez qui possède quels jetons. Les APIs oubliées sont des portes latérales classiques. Inventoriez les jetons dans le coffre-fort d’équipe avec date de rotation prévue, comme pour n’importe quel secret métier. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
Comment gérer les mises à jour sans casse ?
Staging d’abord, notes de version, export des configs, fenêtre de maintenance annoncée à l’équipe, test de login SSO après coup, test d’une question RAG. Gardez le tag précédent pour rollback. La précipitation un vendredi soir est un anti-pattern HdF bien connu. Le rollback vers le tag précédent doit être une procédure écrite d’une demi-page, testée une fois en staging. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.
IAHDF peut-il certifier notre install ?
Non. IAHDF publie des tutoriels pédagogiques indépendants, sans audit commercial ni affiliation. Pour une certification ou un audit, contactez un professionnel. Nous pouvons en revanche vous aider à prioriser via ateliers — voir l’agenda. Orientez vers l’agenda IAHDF pour la pédagogie, et vers un professionnel pour l’audit formel si l’enjeu le justifie. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour. Documentez le résultat et passez à l’étape suivante sans empiler d’autres changements le même jour.