netcup SCP-Apps unter der Haube: Satellite, vsock, Swarm und SBOM prüfen

Die SCP-Apps von netcup installieren Docker-Anwendungen per Mausklick. Doch was passiert dabei auf Ihrem Server, wer steuert die Container, und wie prüfen Sie, was netcup dort laufen lässt? Diese Anleitung schaut hinter die Oberfläche: Sie zeigt Schritt für Schritt den Verwaltungsdienst SCP Server Satellite, den vsock-Kanal zum Hypervisor, den Docker-Swarm-Modus und den Traefik-Proxy. Zum Schluss prüfen Sie Lizenz, Quellcode und Schwachstellen des Satellite-Images selbst, so wie netcup es in seiner Dokumentation beschreibt. Alle Ausgaben stammen von unserem Testserver, einem VPS 500 G12.5 mit dem App-Image, die Befehle folgen der netcup-Dokumentation.

Dies ist Teil 3 der Reihe „netcup Spezial“. Wie Sie Apps installieren und verwalten, zeigt Teil 2.

Voraussetzungen

• netcup-VPS oder Root-Server mit dem App-Image „App Docker Ubuntu 24.04“, siehe Teil 2
• SSH-Zugang als root
• Grundkenntnisse in Docker, siehe Docker Compose unter Linux
• Für die SBOM-Prüfung Platz für das Trivy-Image (bei uns 254 MB) und seine Datenbank sowie Internetzugang des Servers
• Etwa 30 Minuten

Schritt 1: Den Überblick verschaffen

Im SCP sehen Sie unter Apps nur Ihre Anwendungen. Was dahinter läuft, zeigt ein Blick per SSH.

docker ps --format '{{.Names}} | {{.Image}} | {{.Status}}'

traefik_traefik.1.qw7t0aj51b67fyjakukb8lxm8 | traefik:v3.7 | Up 37 minutes (healthy)
traefik_wildcard-cert-export.1.mj5la7p8bel96y9m2z2lvi2sn | alpine:3.20 | Up 37 minutes
scp-server-satellite-server-satellite-1 | cr.netcup.net/scp/server-satellite:1.0-737482 | Up 39 minutes (healthy)
scp-server-satellite-server-satellite-vsock-proxy-1 | alpine/socat:1.8.1.3 | Up 51 minutes (healthy)

Die beiden Container mit scp-server-satellite im Namen gehören zu netcup. Sie laufen als gewöhnliche Compose-Container und nicht im Swarm. Ihre Konfiguration liegt unter /opt/docker/scp-server-satellite/. Die beiden Traefik-Container kamen mit der ersten App dazu. Bei uns war das Uptime Kuma, die App ist inzwischen wieder gelöscht.

Verifizieren: Sie sehen bei sich dieselben zwei Satellite-Container mit Status healthy.

Schritt 2: Den vsock-Kanal verstehen

vsock (virtio-vsock) ist laut netcup ein Kanal, der nur zwischen dem KVM-Hypervisor und Ihrem Server besteht. Er ist keine Netzwerkverbindung und weder aus dem Internet noch von anderen Servern erreichbar. Auf dem Server sehen Sie das Gerät und die Kernelmodule:

ls -l /dev/vsock
lsmod | grep -i vsock

crw-rw-rw- 1 root root 10, 261 Nov  3 20:40 /dev/vsock
vmw_vsock_virtio_transport    20480  0
vmw_vsock_virtio_transport_common    61440  1 vmw_vsock_virtio_transport
vsock                  61440  4 vmw_vsock_virtio_transport_common,vmw_vsock_virtio_transport

Die Brücke baut der Container server-satellite-vsock-proxy. Er bekommt nur das Gerät /dev/vsock und führt socat mit diesem Befehl aus:

VSOCK-LISTEN:8042,fork,max-children=32,reuseaddr
TCP:server-satellite:8083

socat nimmt also auf vsock-Port 8042 Verbindungen vom Hypervisor an und reicht sie an Port 8083 des Agenten im internen Docker-Netz weiter. Der Proxy läuft laut Compose-Datei als Benutzer 65534 (nobody), mit schreibgeschütztem Dateisystem und auf 32 MB Arbeitsspeicher begrenzt. Die Profile von seccomp und AppArmor sind für ihn dagegen abgeschaltet (unconfined). Port 8083 ist nicht auf dem Host veröffentlicht. Unsere Prüfung von außen fand ihn ebenso wenig wie Port 8042. Der praktische Vorteil laut netcup: Das SCP erreicht den Server auch dann, wenn eine Firewall alles Eingehende sperrt oder die öffentliche IP nicht erreichbar ist.

Verifizieren: /dev/vsock existiert, und docker inspect des Proxy-Containers zeigt den socat-Befehl oben.

Schritt 3: Was der Satellite darf

Der eigentliche Agent ist cr.netcup.net/scp/server-satellite. Seine Compose-Datei zeigt, womit er arbeitet:

    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/apps:/opt/apps
      - /opt/docker/scp-server-satellite:/opt/docker/scp-server-satellite
      - /root/.docker:/root/.docker

Mit dem Docker-Socket kann der Agent beliebige Container starten und hat damit praktisch Root-Rechte auf dem Server. Das ist für seine Aufgabe nötig, sollte Ihnen aber bewusst sein: Auf einem App-Server führt ein Dienst von netcup Befehle mit vollen Rechten aus, die über das SCP angestoßen werden. Laut Compose-Datei ist er auf eine CPU und 64 MB Arbeitsspeicher begrenzt. In der Datei scp-server-satellite.env steht nur eine Variable, KEYCLOAK_BASE_URL, die Adresse eines Keycloak-Anmeldedienstes. Passend dazu nutzt der Agent laut pom.xml das Modul quarkus-oidc für die Anmeldung.

Der Satellite aktualisiert sich selbst. Im Ordner fanden wir eine self-update.log und eine Sicherung der vorherigen Compose-Datei. Aus dem Protokoll, gekürzt auf 4 von 9 Zeilen:

 Image cr.netcup.net/scp/server-satellite:1.0-737482 Pulled
 Container scp-server-satellite-server-satellite-1 Recreated
 Container scp-server-satellite-server-satellite-1 Healthy
scp-server-satellite update succeeded

Das Update hatte bei uns die Image-Adresse von scp/server-satellite:1.0-737482 auf cr.netcup.net/scp/server-satellite:1.0-737482 umgestellt, das zeigte diff zwischen docker-compose.yml.previous und docker-compose.yml.

Verifizieren: ls -l /opt/docker/scp-server-satellite/self-update.log zeigt am Datum, wann sich der Agent zuletzt aktualisiert hat.

Schritt 4: Was passiert, wenn der Satellite steht

netcup warnt davor, die Satellite-Container zu stoppen oder zu verändern, weil der Server sonst von den Apps und anderen SCP-Funktionen getrennt wird. Auf unserem Testserver haben wir das bewusst ausprobiert:

cd /opt/docker/scp-server-satellite
docker compose stop server-satellite

Der Reiter Apps im SCP zeigte danach sowohl in der Übersicht als auch unter App installieren nur noch eine Ladeanzeige, eine Fehlermeldung erschien in den rund anderthalb Minuten bis zum Neustart nicht. Mit docker compose up -d im selben Ordner meldete sich der Agent kurz darauf wieder als healthy, und das SCP zeigte den Reiter Apps wieder an.

Verifizieren: Nach einem Eingriff zeigt docker ps beide Satellite-Container wieder als healthy, und der Reiter Apps lädt.

Schritt 5: Docker Swarm mit einem Knoten

Das Image initialisiert den Server als Docker Swarm mit genau einem Knoten:

docker info --format 'Swarm: {{.Swarm.LocalNodeState}}, Manager: {{.Swarm.ControlAvailable}}, Nodes: {{.Swarm.Nodes}}'

Swarm: active, Manager: true, Nodes: 1

Jede App wird ein eigener Stack, bei Uptime Kuma mit dem internen Overlay-Netz uptime-kuma-hfgh_internal. Nach außen geht es nur über das gemeinsame Netz traefik-public. Swarm startet abgestürzte Container selbst neu. Wir haben den Traefik-Container hart beendet:

docker kill $(docker ps -q -f name=traefik_traefik)
docker service ps traefik_traefik --format '{{.Name}} {{.CurrentState}} {{.Error}}'

traefik_traefik.1 Starting 1 second ago
traefik_traefik.1 Failed 6 seconds ago "task: non-zero exit (137)"

Sechs Sekunden nach dem docker kill lief schon ein neuer Container. Wichtig für eigene Eingriffe: Container eines Swarm-Dienstes beenden Sie nicht dauerhaft mit docker kill oder docker stop, Swarm stellt den Sollzustand wie im Test sofort wieder her. Verwalten Sie Apps deshalb über das SCP. Dann bleibt der Stand, den das SCP anzeigt, mit dem Server synchron.

Verifizieren: docker node ls zeigt einen einzigen Knoten mit dem Status Leader.

Schritt 6: Traefik und die Zertifikate

Traefik liegt unter /opt/apps/traefik/. Die Standardadressen unter ncapps.de nutzen ein Wildcard-Zertifikat, in der Konfiguration ist dafür ein Resolver mit DNS-Challenge eingerichtet. Unter /opt/apps/traefik/wildcard-cert/ liegen fullchain.pem und key.pem, daneben läuft der Dienst traefik_wildcard-cert-export. Ein zweiter Resolver nutzt die TLS-Challenge von Let's Encrypt. Eigene Zertifikate tragen Sie laut netcup in /opt/apps/traefik/conf/ssl-certs.yaml ein. Die Datei enthält dafür eine kommentierte Vorlage, die Zertifikatsdateien gehören nach /opt/apps/traefik/ssl-certs/.

Verifizieren: ls /opt/apps/traefik/wildcard-cert/ zeigt fullchain.pem und key.pem.

Schritt 7: Lizenz und Quellcode prüfen

netcup liefert im Satellite-Image Lizenz und Quellcode mit. Den Namen des Images lesen Sie aus der Compose-Datei, die Lizenz aus dem OCI-Label:

COMPOSE_FILE=/opt/docker/scp-server-satellite/docker-compose.yml
IMAGE=$(docker compose -f "$COMPOSE_FILE" config --images server-satellite)
docker inspect --format '{{ index .Config.Labels "org.opencontainers.image.licenses" }}' "$IMAGE"

MIT

Den Lizenztext und das Quellarchiv kopieren Sie aus dem Image, ohne den Agenten zu starten:

id=$(docker create "$IMAGE")
docker cp "$id":/licenses/LICENSE - | tar -Ox | head -5
docker cp "$id":/usr/share/doc/server-satellite/source.tar.gz ./source.tar.gz
docker rm "$id" >/dev/null
mkdir -p scp-server-satellite && tar xzf source.tar.gz -C scp-server-satellite

MIT License

Copyright (c) 2026 netcup GmbH

Permission is hereby granted, free of charge, to any person obtaining a copy

Im Archiv lagen bei uns LICENSE, mvnw, pom.xml und src mit 36 Java-Dateien. Laut pom.xml ist der Agent eine Quarkus-Anwendung mit Modulen wie quarkus-rest und quarkus-oidc. Die Schnittstelle ist im Quellcode nachlesbar: grep -rh '@Path' src listete bei uns unter anderem v1/stacks, v1/logs, v1/networks, v1/registry-logins und v1/self-update. In DockerStackManager.java ruft der Agent die Docker-CLI auf, etwa docker stack deploy --detach=true --resolve-image=never und docker stack rm. Die Labels zeigen außerdem das Basis-Image: Red Hat Universal Base Image 9 Micro.

Verifizieren: ls scp-server-satellite zeigt die vier Einträge.

Schritt 8: Die SBOM auf Schwachstellen prüfen

Das Image enthält eine SBOM, eine maschinenlesbare Liste aller enthaltenen Pakete im SPDX-Format. Sie lesen sie mit docker buildx aus, ohne die Layer des Images zu laden. Wichtig ist laut netcup das .SPDX am Ende, sonst kann Trivy die Datei nicht lesen:

docker buildx imagetools inspect "$IMAGE" --format '{{ json .SBOM.SPDX }}' > sbom.json
ls -l sbom.json

Bei uns war die Datei gut 1 MB groß und listete 346 Pakete, erstellt mit syft 1.51.0. Die Prüfung übernimmt Trivy, hier aus dem Spiegel, den netcup in seiner Dokumentation angibt:

docker run --rm -e TRIVY_NO_PROGRESS=true -v "$(pwd)/sbom.json:/sbom.json:ro" \
  anx-cr.io/hub.docker.com/aquasec/trivy:0.72.0 \
  sbom --skip-version-check /sbom.json

Report Summary
Total: 36 (UNKNOWN: 6, LOW: 1, MEDIUM: 19, HIGH: 10, CRITICAL: 0)

Die 36 Funde betrafen nicht den Java-Code von netcup, sondern ausschließlich Go-Programme im Image: laut SBOM die Docker-CLI /usr/local/bin/docker in Version 29.8.2 und die Plugins docker-compose und docker-buildx, mit ihren Bibliotheken wie golang.org/x/net und der Go-Standardbibliothek. Mit diesen Programmen rollt der Agent laut Quellcode die Stacks aus. Ob eine Lücke im Satellite tatsächlich ausnutzbar ist, sagt die Liste nicht. Sie zeigt aber, wann ein Update des Images fällig ist. Da sich der Satellite selbst aktualisiert, lohnt eine Wiederholung nach jedem Update, erkennbar am Datum der self-update.log.

Verifizieren: Trivy zeigt unter „Report Summary“ eine Zeile „Total:“ mit Aufschlüsselung nach Schweregrad.

Zum Aufräumen löschen Sie die Arbeitsdateien und das Trivy-Image wieder:

rm -r sbom.json source.tar.gz scp-server-satellite
docker rmi anx-cr.io/hub.docker.com/aquasec/trivy:0.72.0

Typische Fehler

Symptom	Ursache und Lösung
Reiter Apps lädt endlos	Satellite gestoppt oder nicht healthy. Im Ordner /opt/docker/scp-server-satellitedocker compose up -d ausführen.
Gestoppter App-Container läuft sofort wieder	Swarm stellt den Sollzustand her. App über das SCP stoppen oder löschen.
Trivy meldet „format=unknown“	Laut netcup fehlt .SPDX im Format, die Datei enthält dann nur einen Rahmen um die SBOM.
docker cp liefert unlesbaren Text	docker cp … - streamt ein tar-Archiv. Mit tar -Ox entpacken.

Häufige Fragen

Kann netcup über den Satellite auf meine Daten zugreifen?

Technisch hat der Agent über den Docker-Socket volle Rechte auf dem Server. Er reagiert auf Anfragen aus dem SCP, und der Quellcode liegt im Image, sodass Sie prüfen können, welche Befehle er annimmt. Als Betreiber des Hypervisors hat ein Hoster ohnehin Zugriff auf die virtuelle Maschine. Für vertrauliche Daten ändert der Satellite daran wenig.

Kann ich den Satellite entfernen?

Dann ist der Server laut netcup von den Apps und weiteren Verwaltungsfunktionen des SCP getrennt. Wer keine SCP-Apps nutzen will, installiert besser ein normales Betriebssystem-Image.

Kann ich eigene Container daneben betreiben?

Das Docker auf dem Server ist ein normales Docker, die Satellite-Container selbst laufen per Compose neben dem Swarm. Beachten Sie aber, dass Traefik die Ports 80 und 443 belegt und alle Container sich die Ressourcen des Servers teilen.

Fazit

Hinter den SCP-Apps steckt ein nachvollziehbarer Aufbau: ein kleiner Agent mit Docker-Rechten, erreichbar nur über den vsock-Kanal des Hypervisors, dazu Docker Swarm und Traefik. netcup legt Lizenz, Quellcode und SBOM offen, das ist bei Hosting-Werkzeugen nicht selbstverständlich. Nutzen Sie das: Ein SBOM-Check dauert wenige Minuten und zeigt, ob das Image aktuell ist.

Weiterführende Anleitungen und Quellen

• Teil 2: SCP-Apps installieren und verwalten
• Teil 1: netcup G12 auf G12.5 umziehen
• Docker Compose unter Linux: die Grundlage
• netcup: Apps im SCP, Abschnitt Funktionsweise
• Docker: Swarm-Modus
• Trivy