Access Lists und Wartungsmodus

Access Lists und der Wartungsmodus beantworten zwei Verwaltungsfragen: wer den Dienst erreichen darf und ob der Dienst während geplanter Arbeiten Kundenverkehr annehmen soll. Verwenden Sie sie als ausdrückliche, prüfbare Kontrollen statt vorübergehender DNS-Änderungen, gelöschter Routen oder undokumentierter Firewall-Ausnahmen.

Richtig eingesetzt behalten erlaubte Clients den Zugriff, abgewiesene Clients werden jedes Mal blockiert, und die Wartung liefert ein bewusstes 503, während Hostname, TLS und Routenkonfiguration bestehen bleiben.

Access Lists kombinieren IP-Regeln und optional HTTP-Basic-Authentifizierung. Wenden Sie die engste Liste an, die die Anforderung erfüllt, und testen Sie sowohl einen erlaubten als auch einen abgewiesenen Client. Behandeln Sie gespeicherte Basic-Auth-Secrets als Zugangsdaten und rotieren Sie sie, wenn sich der Kreis der Berechtigten ändert. Das Löschen einer Liste oder das Ausschalten ihrer Basic-Authentifizierung entfernt ihre Passwortdatei von jedem verbundenen Ingress Node, und die vollständige Synchronisation eines Nodes nach dem erneuten Verbindungsaufbau entfernt Passwortdateien, die keine Konfiguration mehr verwendet.

Access Lists befinden sich auf der Seite Routes auf der Registerkarte Access Lists.

Der Wartungsmodus ist für aktivierte verwaltete Routen verfügbar, die keine rohe Konfiguration verwenden. Er bewahrt den virtuellen HTTP/HTTPS-Host, liefert HTTP 503, pausiert verwaltete Health Checks und macht den Wartungszustand für Alarme und Statusseiten sichtbar.

Verwenden Sie den Wartungsmodus für bewusste, für Kunden sichtbare Arbeiten. Simulieren Sie Wartung nicht durch Löschen einer Route, Deaktivieren von TLS oder Verweisen auf einen Platzhalter-Upstream; diese Aktionen zerstören nützlichen Zustand und erschweren die Wiederherstellung.

Bestätigen Sie vor dem Verlassen des Wartungsmodus, dass der Upstream fehlerfrei ist, Migrationen abgeschlossen sind und abhängige Datenbanken oder Secure Links bereit sind.

Ablauf für Access Lists

1. Legen Sie die kleinste Menge an Erlaubnis- oder Sperrregeln fest, die die vorgesehene Zielgruppe abbildet.
2. Fügen Sie HTTP-Basic-Authentifizierung nur hinzu, wenn der Client die Zugangsdaten schützen und rotieren kann.
3. Hängen Sie die Liste zuerst an eine Testroute oder einen Hostnamen mit geringem Risiko an.
4. Prüfen Sie eine erlaubte und eine abgewiesene Adresse von außerhalb des nginx-Hosts.
5. Prüfen Sie die nginx-Access-Logs, um zu bestätigen, dass die Entscheidung von der vorgesehenen Richtlinie stammt.
6. Hängen Sie die Richtlinie erst an weitere Routen an, wenn der Test eindeutig ist.

Die Änderung einer wiederverwendbaren Access List wirkt sich auf jede angehängte Route aus. Prüfen Sie vor dem Bearbeiten einer gemeinsam genutzten Richtlinie ihre Beziehungen und erstellen Sie eine separate Liste, wenn eine Anwendung eine andere Grenze benötigt.

Sicher in die Wartung wechseln

Bevor Sie den Wartungsmodus aktivieren:

• bestätigen Sie, dass die Route verwaltet und aktiviert ist;
• halten Sie den aktuellen Health-Zustand und das aktive Deployment fest;
• veröffentlichen Sie einen Vorfall auf der Statusseite, wenn Kunden es voraussichtlich bemerken werden;
• stellen Sie sicher, dass Operatoren einen administrativen Zugang behalten, der nicht durch die Anwendungsroute blockiert wird;
• legen Sie fest, welche Prüfung nachweist, dass die Wartungsaufgabe abgeschlossen ist.

Eine Route, die zu einer App gehört, kann auch durch ihre Umgebung oder durch die gesamte App in Wartung versetzt werden. Diese Wartung kommt zum eigenen Schalter der Route hinzu, der seinen Wert behält und wieder gilt, wenn die Wartung der Umgebung oder App endet; die Seite der Route zeigt, woher ihre Wartung stammt. Ein Wartungs-Zugangscode, der für eine Umgebung oder die App ausgestellt wurde, öffnet jede ihrer Routen in Wartung einmal.

Opfield behält den virtuellen Host und das TLS-Verhalten bei, während es 503 liefert. Das macht Monitoring und Kundenkommunikation ausdrücklich und vermeidet DNS- oder Zertifikatsänderungen.

Beenden und prüfen

1. Prüfen Sie den Upstream direkt oder über seinen verwalteten Health Check.
2. Bestätigen Sie, dass Datenbank-Bindings, Migrationen und abhängige Dienste bereit sind.
3. Deaktivieren Sie den Wartungsmodus.
4. Stellen Sie eine externe Anfrage über den kanonischen Hostnamen.
5. Prüfen Sie Statuscode, erwarteten Inhalt, TLS, Umleitungen und gegebenenfalls das WebSocket-Verhalten.
6. Lösen Sie den Vorfall auf der Statusseite erst auf, wenn die externe Prüfung erfolgreich war.

Bleibt die Route nicht verfügbar, aktivieren Sie die Wartung erneut, statt wiederholt unbeteiligte Einstellungen umzuschalten. Verwenden Sie die Fehlerbehebung beim Ingress, um die ausgefallene Ebene zu ermitteln.

Richtlinienauswertung und sichere Änderungen

Dokumentieren Sie, ob die Liste eine administrative Oberfläche, einen privaten Kundenendpunkt oder eine ganze öffentliche Anwendung beschränken soll. Gemischte Erlaubnis- und Sperrregeln werden bei einem Vorfall leicht falsch gelesen, halten Sie die Richtlinie also klein und benennen Sie sie nach der Zielgruppe, die sie schützt. Testen Sie die wirksame Client-Adresse, die nginx sieht, insbesondere wenn Anfragen über ein CDN oder einen anderen vertrauenswürdigen Proxy eintreffen; wer nur die scheinbare Browser-Adresse testet, validiert womöglich die falsche Regel.

Basic-Authentifizierung ergänzt die Netzwerkrichtlinie, ersetzt aber kein TLS. Verwenden Sie sie nur auf HTTPS-Routen, speichern Sie die erzeugten Zugangsdaten über den unterstützten Secret-Weg und übermitteln Sie sie außerhalb von Anwendungslogs oder Tickets. Einen Benutzer aus gemeinsam genutzten Zugangsdaten zu entfernen, erfordert die Rotation dieser Zugangsdaten für alle verbleibenden Benutzer; verwenden Sie getrennte Listen, wenn unabhängiger Widerruf wichtig ist.

Halten Sie vor dem Bearbeiten einer gemeinsam genutzten Access List jede angehängte Route und das aktuelle Verhalten für eine erlaubte und eine abgewiesene Anfrage fest. Nehmen Sie die Änderung einmal vor, warten Sie auf die Bestätigung durch nginx und wiederholen Sie beide Tests. Schlägt die Validierung oder Anwendung fehl, behalten Sie die zuletzt bestätigte Richtlinie bei und korrigieren Sie die neue Revision, statt die Zugriffskontrolle von Produktionsrouten zu lösen.

Notfallwiederherstellung

Eine Access List kann Operatoren aus einer Anwendung aussperren, sollte aber den Administrationszugang zu Opfield nicht blockieren, sofern dieser nicht bewusst hinter dieselbe Richtlinie gestellt wurde. Werden alle erwarteten Clients abgewiesen, prüfen Sie die in den Access-Logs beobachtete Quelladresse und die Konfiguration vertrauenswürdiger Proxys, bevor Sie den erlaubten Bereich erweitern.

Ist eine sofortige Wiederherstellung des Dienstes erforderlich, stellen Sie die vorherige, bekannt fehlerfreie Liste wieder her oder hängen Sie eine eng begrenzte Notfallliste mit kurzer Lebensdauer an. Ersetzen Sie sie nicht durch uneingeschränkten öffentlichen Zugriff, sofern der Verantwortliche für den Vorfall diese Offenlegung nicht ausdrücklich akzeptiert. Entfernen Sie nach der Wiederherstellung vorübergehende Regeln, rotieren Sie Notfall-Zugangsdaten und prüfen Sie jede Route, die die ursprüngliche Liste geteilt hat.