Docker : les droits d'un agent tiennent dans une image

Ce qui se passe

Docker a publié le 24 septembre la Sandbox Kit Specification v3, sous licence Apache 2.0, dans le dépôt docker/sandbox-kit-spec. Elle décrit ce qu'un agent, ou n'importe quelle charge, demande à son environnement : réseau, identifiants, volumes, ports, périphériques, skills. Docker annonce en parallèle vouloir confier la spécification à la CNCF.

Pourquoi ça compte

Un agent utile accumule des droits : un montage, un jeton trop large, une règle de pare-feu ouverte faute de temps. Aucun fichier ne les recense. Ils vivent dans des options de docker run, un fichier Compose, une config de CI, la mémoire de quelqu'un. On ne peut ni les relire, ni les comparer d'une semaine à l'autre, ni les retirer proprement. Un Dockerfile décrit le logiciel ; rien ne décrivait ce qu'il attend du monde extérieur.

Comment c'est construit

• Un Kit est une image OCI ordinaire. Les déclarations tiennent dans une annotation du manifeste, vnd.docker.sandbox.kit.descriptor, et les couches portent le contenu. Le Kit se construit avec docker buildx build, se tire avec docker pull, se scanne et se signe avec l'outillage existant, et s'utilise dans un FROM. Épingler le digest fige le contenu et les droits ensemble.
• Deux sortes. Un workload fournit le système de fichiers racine, un seul par lancement. Un mixin s'y superpose : une CLI et sa règle réseau, un identifiant, du contexte pour l'agent.
• Des capacités typées et versionnées, comme network-policy@2 ou credential@1.

capabilities:
  - type: com.docker.sandbox/network-policy@2
    config:
      runtime:
        allow:
          - github.com
          - hosts: [api.github.com]
            methods: [GET, HEAD, POST, PATCH, PUT, DELETE]
        deny:
          - hosts: [api.github.com]
            methods: [DELETE]
            paths: [/repos/**]

L'API GitHub est joignable, mais pas les DELETE sous /repos/** : le refus l'emporte. Le jeton, lui, passe par un proxy. Le runtime insère la vraie valeur dans les requêtes vers les domaines nommés, et l'intérieur du bac à sable ne voit qu'une valeur sentinelle.

Les garde-fous

• Un Kit demande, l'hôte décide. Une demande obligatoire que l'hôte ne peut satisfaire bloque le lancement, plutôt que de démarrer avec d'autres droits que ceux déclarés.
• La composition suit les provides et les requires, jamais l'ordre des options. Deux Kits qui fournissent le même nom provoquent une erreur au lieu de se masquer l'un l'autre.
• Chaque version se réduit à un ensemble normalisé de droits. Une mise à jour qui l'élargit, y compris en supprimant une règle deny, s'arrête et demande validation.
• Deux suites de conformité accompagnent le texte : l'une pour les Kits, l'autre pour les runtimes.

La limite

Sans runtime conforme, l'annotation est inerte : une image, et aucune règle appliquée. Le seul runtime conforme aujourd'hui est Docker Sandboxes, des microVM qui ont chacune leur noyau, en local ou dans Docker Cloud Sandboxes.

Pour essayer

brew install docker/tap/sbx
git clone https://github.com/docker/sandbox-kit-spec
cd sandbox-kit-spec/examples
sbx run ./hello --kit ./gh .

Le Kit de Claude Code fourni dans le dépôt mérite une lecture : il liste les hôtes, l'identifiant, les volumes persistants et les hooks qu'un agent de code réclame réellement.

Source : From Dockerfile to Kit: the Docker Sandboxes Kit Specification, Docker, 24 septembre 2026.