Sicherheit

Wer was darfLink zum Abschnitt kopieren

Zwei getrennte Mechanismen, die man leicht verwechselt.

access.toml regelt, wer die Cloud bedienen darf, also /mutecloud im Spiel, die HTTP-API und das Dashboard. Rollen bündeln Rechte, Spieler bekommen Rollen:

role list
user add MuteBefehl admin
user info MuteBefehl

Mitgeliefert werden admin mit *, moderator mit Ansehen und Neustarten und viewer nur mit Ansehen. Eigene Rollen legst du mit role create an und füllst sie mit role grant.

ranks.toml dagegen regelt die Rechte der Spieler auf den Servern, also Präfix, Suffix und Bukkit-Permissions, die über die Bridge verteilt werden. Nutzt du LuckPerms, lässt du die Datei leer, dann hält sich MuteCloud ganz aus der Rechteverwaltung heraus.

TokensLink zum Abschnitt kopieren

Das Token in der mutecloud.toml unter [api] gewährt vollen Zugriff. Für alle anderen Nutzer:

token create website groups.view players.view

Jedes Token bekommt nur die Rechte, die es braucht. token list zeigt, wann jedes zuletzt benutzt wurde.

Nach acht falschen Tokens wird eine Adresse für eine Minute gesperrt, bei HTTP genauso wie beim WebSocket, und es geht eine Meldung raus. Das Dashboard hat dieselbe Bremse nach fünf Versuchen, zusätzlich über alle Adressen hinweg.

Audit-LogLink zum Abschnitt kopieren

Jeder Befehl von außen wird in audit.log festgehalten:

2026-09-15T05:40:12Z spiel MuteBefehl ok groups Lobby stop
2026-09-15T05:41:03Z rest website verweigert:groups.stop groups Lobby stop

Erfasst werden der Weg über das Spiel, die API und das Dashboard. Lesen kannst du es mit audit oder audit 50, das Recht dafür ist *. Das Log rotiert täglich und wird neunzig Tage aufbewahrt, einstellbar unter [logs].

DateienLink zum Abschnitt kopieren

mutecloud.toml und access.toml gehören nur dem Besitzer, sie enthalten Tokens und Passwort-Hashes. Dasselbe gilt für forwarding.secret in der Proxy-Vorlage. Dashboard-Passwörter werden als Argon2id-Hashes gespeichert.

DashboardLink zum Abschnitt kopieren

Standardmäßig aus. dashboard on schaltet es ein, dashboard password <new> setzt das gemeinsame Passwort, user password <name> <new> gibt einem Spieler einen eigenen Zugang mit seinen Rollen.

Für den öffentlichen Betrieb legst du eine Domain und eine Mailadresse fest, dann holt die Cloud ein Zertifikat von Let's Encrypt:

dashboard domain cloud.example.com
dashboard contact [email protected]

Welche Adressen erlaubt sind und was das Dashboard kann, steht unter Dashboard, Warnungen und Metriken.

Im VerbundLink zum Abschnitt kopieren

Nodes werden nur innerhalb eines privaten Netzes verbunden. Worker verbinden sich nur mit privaten Adressen, und der Leiter nimmt Nodes und Vorlagen-Downloads nur aus privaten Netzen an. Siehe Nur privates Netzwerk.

PortsLink zum Abschnitt kopieren

Die API lauscht standardmäßig auf 127.0.0.1:8770 und ist dann nur vom Server selbst aus erreichbar. Ein Verbund braucht sie zu den Workern hin offen, sonst nichts. Binde sie nach Möglichkeit an die private Adresse statt an 0.0.0.0 und mach sie nie öffentlich zugänglich. Spielserver müssen aus dem Internet überhaupt nicht erreichbar sein. Spieler verbinden sich mit dem Proxy, der Proxy mit den Servern, und ein Spielserver, der für alle offen ist, lässt Leute am Proxy und seinen Strafen vorbeilaufen.