AI-spezifisches Docker Image

Für die ai- und ai-agent-Container wird ein separates Docker Image genutzt.

Dabei wird Claude Code im Dockerfile über NPM¹ installiert und steht anschließend als CLI im Container zur Verfügung.

Neben der Installation der Claude Code CLI wird zusätzliche Software für die Nutzung der Claude Code Sandbox installiert.

Bei der Installation gibt es zwei gängige Ansätze: Installation als root- oder als node-User

Dockerfile

USER root
RUN npm install -g @anthropic-ai/claude-code@2.1.78
USER node

Hier erfolgt die Installation als root. Anschließend wird in den node-User gewechselt, sodass Claude Code zur Laufzeit nicht mit Root-Rechten ausgeführt wird.

Der Vorteil dieser Variante: Die installierten Dateien gehören root und sind damit für den node-User nicht veränderbar.

In einem gehärteten Container erhöht dies die Integrität des global installierten Tools.

Dockerfile

RUN mkdir -p /usr/local/share/npm-global \
  && chown -R node:node /usr/local/share/npm-global
ENV NPM_CONFIG_PREFIX=/usr/local/share/npm-global
ENV PATH=$PATH:/usr/local/share/npm-global/bin
USER node
RUN npm install -g @anthropic-ai/claude-code@2.1.78

Diese Variante folgt dem Prinzip “Least Privilege auch zur Build-Zeit” und orientiert sich am offiziellen Claude Code Development Container.

Dabei wird ein eigener globaler npm-Pfad eingerichtet, der dem node-User gehört. Die Installation erfolgt anschließend ohne Root-Rechte.

Vorteile:

• Installation erfolgt ohne Root-Rechte
• näher am Dockerfile des offiziellen Claude Code Development Containers

Nachteil:

Der node-User kann den globalen npm-Pfad zur Laufzeit verändern. Damit könnten globale CLI-Binaries durch nachgelagerten Code überschrieben oder manipuliert werden.

Der Dockerfile-Build ist eine einmalige, deterministische Aktion mit gepinnter Version der Claude-Code-Dependency.

Der größte Angriffsvektor entsteht typischerweise nicht während der Installation der Claude Code CLI, sondern durch zur Laufzeit ausgeführten Anwendungscode oder NPM-Dependencies innerhalb eines Projekts.

Der offizielle Claude Code Development Container verfolgt ein anderes Ziel: eine interaktive Entwicklungsumgebung, in der Nutzer nach dem Build weitere globale Tools installieren können. In diesem Fall ist der node-User Ansatz gut geeignet.

Claude Code nutzt bubblewrap als zusätzliche² Sandbox. Diese Sandbox sorgt dafür, dass ein ausgeführter Prozess nur auf bestimmte Dateien zugreifen darf und der Netzwerkzugriff eingeschränkt wird.

Für den Netzwerkzugriff wird innerhalb des Containers zusätzlich socat verwendet. Dabei wird der Netzwerkverkehr des Prozesses in der Sandbox über einen lokalen Proxy geleitet, der anhand der Sandbox-Settings entscheidet, welche Domains erlaubt oder blockiert sind.

Beide Komponenten laufen ausschließlich innerhalb des Containers und haben keine Auswirkungen auf das Host-System.

Dockerfile

...
RUN apt-get update \
  && apt-get install -y --no-install-recommends \
    bubblewrap \
    socat \
...

Unter Docker Desktop auf macOS läuft der Container in einer internen Linux-VM. In dieser VM sind bestimmte Funktionen deaktiviert, die Bubblewrap benötigt, um eine eigene Sandbox zu erstellen.

Bubblewrap kann daher nicht vollständig aktiviert werden.

Eine Aktivierung wäre nur möglich, wenn man der Docker-VM zusätzliche privilegierte Rechte gibt. Das würde jedoch dem Hardening-Ansatz dieser Guideline widersprechen.

Bubblewrap wurde primär für Szenarien entwickelt, in denen Prozesse direkt auf einem Linux-System isoliert werden müssen. In der Umgebung dieser Guideline läuft Claude Code jedoch bereits innerhalb eines gehärteten Docker-Containers.

Eine vollständige Aktivierung von Bubblewrap würde zusätzliche privilegierte Rechte in der Docker-VM erfordern.

Damit würde die äußere Isolationsschicht geschwächt, um eine zusätzliche innere Schicht zu ermöglichen, was das Gesamtsystem eher unsicherer machen würde.

Im ai- und ai-agent-Container wird enableWeakerNestedSandbox aktiviert. Diese Option nutzt eine abgeschwächte Sandbox innerhalb des Containers und ist speziell für unprivilegierte Docker-Umgebungen vorgesehen.

Sie bietet weniger starke Isolation als Bubblewrap, ergänzt jedoch sinnvoll die bestehende Docker-Härtung, ohne zusätzliche privilegierte Rechte zu erfordern.