Skip to main content

Eggs, Nests & Images

Eggs, Nests und Docker Images bilden das technische Fundament jedes Game-Servers in Pterodactyl. Sie definieren nicht nur, was gestartet wird, sondern wie, mit welchen Rechten und unter welchen Risiken.

Fehler in diesem Bereich sind eine der häufigsten Ursachen für:

  • Sicherheitsvorfälle
  • instabile Server
  • unerklärliche Performance-Probleme

1. Begriffsklärung (präzise)

1.1 Nest

Ein Nest ist eine logische Gruppierung von Eggs. Es besitzt keine technische Funktion zur Laufzeit, sondern dient ausschließlich:

  • der Organisation
  • der Übersicht im Panel
  • der Trennung nach Spieltypen

Beispiele:

  • Minecraft
  • Source Engine
  • Voice Server

1.2 Egg

Ein Egg ist eine vollständige, deklarative Beschreibung, wie ein Game-Server ausgeführt wird.

Ein Egg definiert:

  • Docker Image
  • Startbefehl
  • Environment-Variablen
  • Port-Definitionen
  • Dateistrukturen

Ein Egg ist funktional vergleichbar mit:

Dockerfile + Runtime-Konfiguration + Sicherheitskontext

1.3 Docker Image

Das Docker Image enthält die eigentliche Laufzeitumgebung:

  • Betriebssystem-Basis
  • Runtime (Java, Node.js, SteamCMD, etc.)
  • Abhängigkeiten

Images sind:

  • immutable
  • versionierbar
  • kritische Sicherheitskomponenten

2. Interner Ablauf beim Start eines Game-Servers

  1. Panel liest Egg-Definition
  2. Wings validiert Variablen & Limits
  3. Docker Image wird (falls nötig) gepullt
  4. Container wird mit exakt definiertem Startkommando erstellt
  5. Volumes werden eingebunden
  6. Ports werden gemappt
  7. Container wird gestartet

Wichtig: Kein einziger dieser Schritte ist „dynamisch geraten“, alles ist hart durch das Egg definiert.

3. Aufbau eines Eggs (technisch)

Ein Egg besteht intern aus einer JSON-Struktur mit:

  • Startup Command
  • Default Environment
  • Install Script
  • Variable Validation Rules

3.1 Startup Command

Der Startup Command wird direkt an Docker übergeben.

Typische Fehler:

  • Shell-Expansion ohne Validierung
  • Unsichere Parameterübergabe
  • Unkontrollierte User-Eingaben

Ein fehlerhaftes Startup Command ist ein direkter Angriffsvektor.

3.2 Environment-Variablen

Environment-Variablen werden:

  • im Panel definiert
  • beim Containerstart injiziert

Gefahren:

  • Command Injection
  • Pfad-Manipulation
  • Missbrauch von JVM-Flags

Jede Variable muss:

  • validiert
  • typisiert
  • begrenzt

3.3 Install Scripts

Install Scripts laufen innerhalb des Containers mit weitreichenden Rechten.

Typische Risiken:

  • Download fremder Skripte
  • Ungeprüfte Curl | Bash Konstrukte
  • Manipulation des Dateisystems

Install Scripts sind der größte Supply-Chain-Risikofaktor.

4. Community Eggs vs. Eigene Eggs

4.1 Community Eggs

Vorteile:

  • Schnell einsetzbar
  • Große Auswahl

Nachteile:

  • Unbekannte Code-Qualität
  • Unklare Wartung
  • Teilweise massive Sicherheitsprobleme

Community Eggs dürfen niemals ungeprüft produktiv eingesetzt werden.

4.2 Eigene Eggs (empfohlen)

Eigene Eggs ermöglichen:

  • vollständige Kontrolle
  • saubere Versionierung
  • angepasste Performance-Parameter

Im Hosting-Betrieb sind eigene Eggs faktisch Pflicht.

5. Image-Strategien (entscheidend)

5.1 Image-Versionierung

Best Practice:

  • Explizite Versions-Tags
  • Kein latest im Produktivbetrieb

Warum:

  • Reproduzierbarkeit
  • Rollback-Fähigkeit
  • Stabile Updates

5.2 Eigene Images

Eigene Images erlauben:

  • Reduzierte Angriffsfläche
  • Gezielte Optimierungen
  • Fixierte Runtime-Versionen

Images sollten:

  • minimal sein
  • regelmäßig neu gebaut werden
  • keine unnötigen Tools enthalten

6. Sicherheitsrisiken aus der Praxis

  • Eggs mit Root-Shell-Zugriff
  • Unsichere JVM-Flags
  • Ungefilterte Variablen
  • Manipulierte Community Images

Diese Risiken umgehen Container-Isolation effektiv.

7. Performance-Fallen

  • Debug-Flags im Startup
  • Zu viele JVM-Parameter
  • Unoptimierte Garbage Collection
  • Falsche Thread-Konfiguration

Eggs beeinflussen Performance stärker als viele Administratoren vermuten.

8. Best Practices (Venasty Systems Standard)

  • Eigene Eggs für alle produktiven Games
  • Eigene Images mit festen Versionen
  • Keine ungeprüften Community Eggs
  • Strikte Variablenvalidierung
  • Install Scripts minimal halten

9. Fazit

Eggs sind kein Konfigurationsdetail, sondern das sicherheits- und performancekritischste Element in Pterodactyl.

Wer Eggs beherrscht, beherrscht die Plattform.

Venasty Systems betrachtet Eggs und Images als Kernbestandteil seiner Plattform-Sicherheitsarchitektur und behandelt sie entsprechend streng.

Back to top