Clé d'API Ollama : votre Ollama local n'en a pas. Voici comment en exiger une

Par MV2 de Munim, Inc. Vérifié le 12 octobre 2026 d'après la documentation d'authentification d'Ollama, la FAQ d'Ollama, la documentation n8n sur les identifiants Ollama, la documentation de l'API d'Open WebUI et la documentation des matchers de Caddy. Uniquement pour vos propres machines. Cette page a été traduite avec une IA à partir de l'original en anglais ; en cas d'écart, l'original fait foi.

La réponse courte

Si Ollama n'est utilisé que sur la machine où il tourne, vous n'avez besoin de rien de tout cela. Laissez-le sur 127.0.0.1 ; la liste de contrôle de sécurisation montre comment le vérifier.

Option A : Open WebUI tourne déjà ? Utilisez-le comme porte d'entrée

Open WebUI relaie les requêtes vers Ollama sous /ollama/ et vérifie ses propres clés d'API. Ollama reste interne, et aucun logiciel supplémentaire n'est nécessaire.

  1. Créez une clé dans Open WebUI sous Settings > Account (dans l'interface française, « Paramètres » puis « Compte » ; les clés commencent par sk-). Si l'option n'apparaît pas, un administrateur doit d'abord autoriser les clés d'API ; voir la documentation d'Open WebUI sur les clés d'API.
  2. Appelez l'API native d'Ollama via Open WebUI : 
    curl https://webui.example.home/ollama/api/tags -H "Authorization: Bearer sk-..."
    ou utilisez le point d'accès compatible OpenAI d'Open WebUI, /api/chat/completions.
  3. Dans n8n, réglez la Base URL de l'identifiant Ollama sur https://webui.example.home/ollama et son API Key sur la clé sk-. La documentation de n8n cite Open WebUI comme exemple de cette configuration.

La clé porte les droits de cet utilisateur d'Open WebUI : créez donc un utilisateur distinct par application, et tenez Open WebUI à jour (voir les avis de sécurité d'Open WebUI (en anglais)).

Option B : un petit proxy qui vérifie une clé

1. Garder Ollama en local et créer une clé

Ollama doit écouter sur 127.0.0.1:11434 (la valeur par défaut). Si vous avez défini OLLAMA_HOST=0.0.0.0 auparavant, annulez-le comme à l'étape 2 de la liste de contrôle. Sinon, on peut contourner le proxy en allant directement sur le port 11434. Générez ensuite une longue clé aléatoire :

openssl rand -hex 32
# or
python3 -c "import secrets; print(secrets.token_urlsafe(32))"

(Une seule des deux commandes suffit.)

2a. Caddy

Caddy obtient tout seul un certificat HTTPS quand ollama.example.com est un vrai domaine qui pointe vers cette machine. Remplacez le domaine et PASTE_YOUR_KEY_HERE (par votre clé) :

ollama.example.com {
    @key header Authorization "Bearer PASTE_YOUR_KEY_HERE"
    handle @key {
        reverse_proxy 127.0.0.1:11434 {
            header_up Host localhost:11434
            header_up -Authorization
        }
    }
    handle {
        respond "Missing or wrong API key" 401
    }
}

Nom valable seulement sur le réseau local (comme ollama.home) : il n'y a pas de certificat public, utilisez donc tls internal dans le bloc du site et installez le certificat racine de Caddy sur vos clients. Ou passez-vous du proxy et utilisez un réseau privé comme Tailscale ou WireGuard (voir Utiliser Ollama à distance). N'envoyez pas la clé en http:// non chiffré sur un réseau auquel vous ne faites pas confiance ; n'importe qui sur ce réseau pourrait la lire.

2b. nginx

Placez ceci dans /etc/nginx/conf.d/ollama.conf. Les fichiers de conf.d sont lus à l'intérieur du bloc http, là où map doit se trouver. Utilisez vos propres chemins de certificat, par exemple ceux de certbot :

map $http_authorization $ollama_key_ok {
    default                        0;
    "Bearer PASTE_YOUR_KEY_HERE"   1;
}

server {
    listen 443 ssl;
    server_name ollama.example.com;
    ssl_certificate     /etc/letsencrypt/live/ollama.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ollama.example.com/privkey.pem;

    location / {
        if ($ollama_key_ok = 0) { return 401; }
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
        proxy_set_header Authorization "";   # don't pass the key on to Ollama
        proxy_buffering off;                 # stream tokens as they come
        proxy_read_timeout 600s;             # long generations
        client_max_body_size 0;              # model uploads (ollama create)
    }
}

(Les commentaires signifient, dans l'ordre : ne pas transmettre la clé à Ollama ; envoyer les tokens au fil de l'eau ; autoriser les longues générations ; autoriser l'envoi de modèles avec ollama create.) Ajoutez une ligne à la map pour chaque clé supplémentaire. Lancez ensuite sudo nginx -t && sudo systemctl reload nginx, et rendez le fichier lisible uniquement par root (sudo chmod 600 /etc/nginx/conf.d/ollama.conf ; nginx le lit en tant que root au démarrage).

2c. Ollama dans Docker

Ne donnez aucun ports: au service ollama et ne publiez que Caddy. Dans le Caddyfile ci-dessus, utilisez reverse_proxy ollama:11434. Ajoutez vos réglages GPU habituels au service ollama.

services:
  ollama:
    image: ollama/ollama
    volumes: [ "ollama:/root/.ollama" ]
    # no "ports:" - only containers on this network can reach it
  caddy:
    image: caddy:2
    ports: [ "80:80", "443:443" ]
    volumes: [ "./Caddyfile:/etc/caddy/Caddyfile:ro", "caddy_data:/data" ]
volumes:
  ollama: {}
  caddy_data: {}

(Le commentaire signifie : pas de « ports: », seuls les conteneurs de ce réseau atteignent Ollama.)

3. Tester

# no key: should print 401
curl -s -o /dev/null -w "%{http_code}\n" https://ollama.example.com/api/version

# with the key: should print {"version":"..."}
curl -H "Authorization: Bearer YOUR_KEY" https://ollama.example.com/api/version

# from ANOTHER machine, straight to Ollama: should fail to connect
curl http://<server LAN IP>:11434/api/version

(Résultats attendus : sans clé, 401 ; avec la clé, la version ; et depuis une AUTRE machine, directement vers Ollama, la connexion doit échouer. YOUR_KEY est votre clé et <server LAN IP> l'IP locale du serveur.) Si la dernière commande répond par une version, le proxy peut être contourné. Revérifiez OLLAMA_HOST et les ports: de Docker. Sous Linux, ufw ne bloque pas les ports publiés par Docker.

Connecter vos applications

Erreurs à éviter

Vous préférez une vérification faite pour vous ?

MV2 de Munim, Inc. propose un bilan d'IA locale à 49 USD pour une machine, ou un bilan petit bureau à 199 USD pour jusqu'à 5 machines ou un serveur Ollama ou Open WebUI partagé. Vous recevez un rapport écrit sur ce qui est exposé, risqué ou lent et sur ce qu'il faut corriger en premier, avec les commandes exactes pour votre système. Le rapport est rédigé en anglais. Voir un exemple de rapport (en anglais). Payer 49 USD ou payer 199 USD sur Stripe, puis envoyez à munimversion2@gmail.com la sortie de python3 local_ai_checkup.py --json du script gratuit local-ai-checkup, votre système d'exploitation et l'usage que vous en faites. MV2 ne demande jamais de mots de passe, de clés ni d'accès à distance : n'envoyez donc pas votre clé d'API.