DLDanpLab
This article is available in Italian only.
DanpLab · Lab NoteArchitettura operativa

Docker Model Runner: come mettere in sicurezza i modelli AI locali

Una guida operativa per ridurre la superficie d’attacco di Docker Model Runner: aggiornamenti, fiducia nei modelli, isolamento, inventario e controlli prima di portare l’inferenza locale in produzione.

5 min readBased on real operational use
DockerSicurezzaAI self-hostedHomelab

Eseguire un modello linguistico sul proprio computer o nel laboratorio domestico evita di inviare dati a un servizio esterno, ma “locale” non significa automaticamente “sicuro”. Un modello distribuito come artefatto può includere tokenizer, configurazioni e codice personalizzato; inoltre il servizio di inferenza diventa una nuova API raggiungibile dalle applicazioni. Docker Model Runner semplifica il ciclo di vita dei modelli, ma va trattato come un componente infrastrutturale privilegiato, non come una semplice immagine statica.

Il tema è concreto. Gli avvisi di sicurezza Docker del 2026 hanno documentato vulnerabilità di esecuzione di codice dal container all’host nei backend di inferenza su macOS, tra cui CVE-2026-5817 per vllm-metal e CVE-2026-5843 per MLX. Nel primo caso, il caricamento non isolato di tokenizer con codice remoto attendibile poteva trasformare un modello ostile in codice eseguito fuori dal confine atteso. La lezione vale oltre la singola CVE: modello, tokenizer e relativo repository fanno parte della supply chain software.

Prima azione: aggiornare e ridurre l’esposizione

La correzione prioritaria è installare l’ultima versione stabile di Docker Desktop disponibile per il proprio sistema. Non basta aggiornare le immagini applicative: Model Runner è un componente di Docker Desktop e la correzione deve arrivare dal prodotto che ospita il backend. Dopo l’aggiornamento, riavviare Docker Desktop e controllare la versione effettivamente in esecuzione:

docker version
docker info

Su flotte gestite conviene raccogliere questi output con l’inventario aziendale e confrontarli con le release note, evitando di fidarsi soltanto del pacchetto scaricato. Se Model Runner non serve, disabilitarlo dalle impostazioni di Docker Desktop. La superficie d’attacco migliore è quella che non esiste: non ha senso mantenere un endpoint di inferenza attivo “per eventuali test”.

Se invece è necessario, evitare di esporne l’API tramite port forwarding verso LAN, VPN o Internet. Un reverse proxy con autenticazione non rende sicuro un backend non aggiornato e aggiunge un altro livello da mantenere. Le applicazioni che devono consumare il modello dovrebbero risiedere in reti Docker dedicate, senza condividere automaticamente la rete con stack non correlati.

I modelli sono dipendenze eseguibili

Il controllo più importante avviene prima del pull. Usare modelli provenienti da publisher noti, verificare repository e licenza, preferire versioni immutabili e registrare il digest quando il formato e il registry lo consentono. Un tag come latest è comodo in laboratorio, ma non è una base riproducibile: oggi e domani può indicare contenuti diversi.

Un processo minimo di ammissione dovrebbe registrare:

  • origine e proprietario del modello;
  • nome, versione, digest e data di acquisizione;
  • backend richiesto e architettura host;
  • presenza di codice personalizzato o tokenizer remoto;
  • licenza e limitazioni d’uso;
  • esito della scansione e responsabile dell’approvazione.

Non importare modelli suggeriti da prompt, ticket o utenti senza una revisione. Un agente AI capace di scegliere e scaricare autonomamente un modello amplia il confine di fiducia: l’input dell’utente può diventare una richiesta di esecuzione indiretta. Separare quindi la funzione di chat dalla funzione amministrativa che effettua pull, rimozioni o cambi di backend.

Isolamento pratico per homelab e piccoli ambienti

Una VM dedicata resta il confine più comprensibile quando si provano modelli non pienamente fidati. Lo snapshot facilita il ritorno allo stato precedente, ma non sostituisce il backup; inoltre una cartella host montata nella VM può comunque esporre dati importanti. Per i test usare una VM senza credenziali personali, chiavi SSH, socket Docker esterni o condivisioni della directory home.

All’interno di Docker applicare comunque il minimo privilegio alle applicazioni client: utente non root, filesystem in sola lettura quando possibile, capability rimosse, nessun mount di /var/run/docker.sock e segreti forniti solo al processo che ne ha bisogno. Model Runner non giustifica l’uso del socket Docker dentro una web UI o un workflow engine.

Esempio di profilo Compose per un client che non deve amministrare l’host:

services:
  ai-client:
    image: registry.example/ai-client@sha256:DIGEST_VERIFICATO
    read_only: true
    cap_drop: ["ALL"]
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /tmp:size=128m,noexec,nosuid
    networks:
      - ai_backend

networks:
  ai_backend:
    internal: true

La rete internal limita l’uscita ordinaria dello stack, ma non va considerata una correzione universale per vulnerabilità del runtime o endpoint speciali forniti da Docker Desktop. Serve difesa in profondità: patch del prodotto, controllo degli artefatti e separazione dell’host restano indispensabili.

Osservabilità e risposta

Conservare log di pull, avvio del modello ed errori del backend. Stabilire una baseline: quali modelli devono essere presenti, chi può aggiungerli e quali applicazioni effettuano inferenza. Una variazione inattesa dell’inventario è un evento da investigare, non semplice manutenzione.

Dopo un sospetto modello malevolo, non limitarsi a rimuoverlo. Isolare l’host, acquisire log e inventario, ruotare i segreti raggiungibili, verificare persistenze e ricreare l’ambiente da una base nota. Se la macchina conteneva credenziali aziendali, trattare il caso come possibile compromissione dell’host. Lo snapshot precedente può accelerare l’analisi, ma ripristinarlo senza capire l’origine reintroduce facilmente lo stesso artefatto.

Checklist operativa

Prima di abilitare Docker Model Runner:

  • aggiornare Docker Desktop e verificare la versione in esecuzione;
  • consultare gli avvisi di sicurezza Docker per il backend utilizzato;
  • disabilitare Model Runner dove non necessario;
  • ammettere solo modelli con origine, versione e digest registrati;
  • vietare pull autonomi attivati da prompt o input non attendibili;
  • non pubblicare l’API sulla rete senza una necessità documentata;
  • isolare i test rischiosi in una VM priva di credenziali e mount sensibili;
  • applicare minimo privilegio ai container client;
  • monitorare modifiche all’inventario dei modelli;
  • provare una procedura di revoca, ricostruzione e rotazione dei segreti.

L’AI self-hosted offre controllo sui dati, latenza prevedibile e costi più trasparenti. Quel controllo, però, include la responsabilità della supply chain. Considerare i modelli come pacchetti potenzialmente eseguibili porta a decisioni migliori: fonti approvate, versioni bloccate, ambienti separati e aggiornamenti tempestivi.

Fonti