Firewall
Wer deine Workloads erreichen darf und was sie erreichen dürfen. Standardmässig zu, mit drei Schaltern für den Rest.
Auf dieser Seite
Was das ist
Jedes Projekt startet geschlossen. Von aussen kommt niemand hinein, und was hinausgeht, bestimmen drei Schalter, die dir gehören. Auf dieser Grundlage schreibst du Regeln für den Verkehr, den du wirklich willst.
Dieser Weg funktioniert ab Werk. Alles, was nicht darauf liegt, braucht eine Regel. Genau das ist der Sinn: Ein Workload, dem niemand Zugriff gegeben hat, ist ein Workload, den niemand erreicht.
Wann du das brauchst
- Du willst einschränken, welche Apps im Projekt seine Datenbank erreichen dürfen.
- Eine App muss eine externe API aufrufen, während das Projekt sonst dicht ist.
- Du willst belegen, dir selbst oder einer Revision, womit ein Workload tatsächlich sprechen kann.
Die drei Standardwerte
| Schalter | Standard | Was Ausschalten bedeutet |
|---|---|---|
| Talk to project apps | an | Workloads im Projekt erreichen einander nicht mehr. Deine App verliert ihre Datenbank. |
| Resolve names (DNS) | an | Nichts im Projekt löst noch Namen auf. Fast alles bricht, inklusive allem, was an einem Hostnamen hängt. |
| Reach the internet | an | Keine ausgehenden Verbindungen ins öffentliche Internet. Ein abgeschottetes Projekt, was eine echte und laute Anforderung ist. |
Diese Schalter gelten projektweit. Schaltest du einen aus, gilt das für jeden Workload. Behandle sie als Haltung und nicht als Regler.
Resolve names (DNS) auszuschalten bricht mehr, als es aussieht. Namen lösen nirgends mehr auf, und die Fehler zeigen sich als Timeouts an unbeteiligten Stellen statt als klare Ablehnung.
Eine Regel schreiben
Öffne Network und wähl New rule. Eine Regel benennt die Workloads, für die sie gilt, eine Gegenstelle und Ports, und sie ist entweder Allow oder Deny. Einen Domainnamen kannst du nur erlauben. Willst du ihn sperren, lässt du ihn aus deinen Allow-Regeln weg. Solange Reach the internet an ist, ändert eine ausgehende Allow-Regel nichts.
klickops kann Regeln auch aus beobachtetem Verkehr ableiten. Statt zu raten, womit eine App spricht, lässt du sie laufen und lässt dir dann die Regeln vorschlagen, die zu den gesehenen Flows passen. Lies sie durch, bevor du sie übernimmst: Beobachteter Verkehr enthält, was passiert ist, und nicht nur, was passieren sollte.
Sehen, was läuft
Die Seite Network zeigt den Verkehr, den jeder Workload tatsächlich erzeugt hat, auch blockierte Verbindungen. Die blockierte ist die nützliche: Wähl bei ihr Allow, und klickops entwirft die fehlende Regel, statt dich aus einem Timeout raten zu lassen.
Grenzen und Fallstricke
- Verkehr im Projekt ist durch diese Regeln nicht verschlüsselt. Die Firewall entscheidet, wer verbinden darf, nicht wie die Verbindung aussieht.
- Allow-Regeln fügen nur hinzu. Solange ein Standardwert an ist, ändert eine Allow-Regel daneben nichts. Um etwas zu schliessen, schaltest du den Standardwert aus oder legst eine Deny-Regel an.
- Internet heisst öffentliches Internet. Reach the internet und Regeln aufs öffentliche Internet erreichen nie private Netze oder interne Adressen des Hosting-Anbieters, und eine Regel auf einen Domainnamen muss einen öffentlichen Dienst nennen. Hat dein Plattform-Admin den Internetzugang abgeschaltet, bleibt der Schalter aus.
- Ablehnungen sehen aus wie Hänger. Eine blockierte Verbindung läuft meistens in einen Timeout statt abgewiesen zu werden. Eine rätselhaft langsame Anfrage lohnt darum einen Blick auf die Seite Network.
- Das braucht eine Netzwerkschicht (Cilium). Ohne sie sagt dir die Seite Network das und bietet weder Schalter noch Regeln an. Apps laufen trotzdem, erreichen einander und das Internet mit den Standards der Plattform.