Secure Links

Secure Links verbinden unterstützte, von Opfield verwaltete Ressourcen, ohne das Ziel zu einem allgemeinen öffentlichen Endpunkt zu machen.

Der Begriff umfasst eng begrenzte private Konnektivität mit dauerhafter Zuständigkeit in Opfield. Er bedeutet nicht, dass jeder private Pfad dieselbe Laufzeitkomponente verwendet. Upstream-Verbindungen für Ingress und Bindings verwalteter Datenbanken haben unterschiedliche Eigentümer, Zugangsdaten, Lebenszykluseinträge und Diagnosesignale.

Voraussetzungen und Vertrauensgrenze

Beide Endpunkte müssen unterstützte, von Opfield verwaltete Ressourcen mit stabilen Identitäten sein, und ihre zuständigen Nodes müssen mit kompatiblen Fähigkeiten online sein. Relay muss fehlerfrei laufen und von den beteiligten Nodes erreichbar sein. Der Aufrufer benötigt die Berechtigung, die Zielressource zu lesen und die Ressource zu ändern, der die Beziehung gehört.

Wählen Sie den Anwendungsdienst oder Port, auf dem der Prozess tatsächlich lauscht. Ein veröffentlichter Host-Port ist nicht erforderlich, nur um eine private Verbindung zu erstellen, und das Öffnen eines solchen Ports repariert keinen fehlgeschlagenen privaten Pfad. Opfield erstellt keine Firewall-Regeln auf dem Host und macht keine beliebigen Netzwerke erreichbar.

Datenbank-Bindings

Ein Binding einer verwalteten Datenbank verbindet einen geeigneten Container, ein Deployment oder einen Compose-Dienst mit einer verwalteten Datenbank. Opfield erstellt für das Binding einen eigenen Engine-Benutzer bzw. eine eigene Rolle und vergibt nur die benötigten Datenbankberechtigungen. Es liefert dem Workload Binding-spezifische Verbindungsdaten; die Zugangsdaten des Datenbankbesitzers werden nicht offengelegt.

Der Workload erreicht die Datenbank über den gemeinsamen Secure-Link-Connector seines Docker Nodes, in einem kleinen eigenen privaten Netzwerk für das Binding. Es gibt keinen Connector-Container pro Binding und keinen Host-Listener, der neu gestartet, geprüft oder ersetzt werden müsste. Die Verbindung und die Engine-Identität sind getrennte, aber koordinierte Einträge, sodass die Rotation von Zugangsdaten, eine Berechtigungsänderung oder das Löschen bei einem Workload nicht stillschweigend ein anderes Binding verändert.

Das Neuerstellen des Workloads hält das Binding verfügbar, weil die Autorisierung der stabilen Opfield-Ressourcenidentität folgt und nicht einer vorübergehenden Container-ID. Opfield gleicht die Verbindung ab und speist die aktuellen Verbindungseinstellungen erneut ein. Das Löschen des Bindings entfernt die Verbindung und setzt seine Engine-Identität in einem einzigen erfassten Lebenszyklus außer Kraft; der normale Weg darf keine verwaisten Rollen oder Benutzer hinterlassen.

Prüfen Sie bei einem fehlgeschlagenen Datenbank-Binding zuerst die verwaltete Datenbank und den Storage Node, dann den Ziel-Docker-Node und den Workload, den Sollzustand des Bindings, den Secure-Link-Connector des Nodes, die Engine-Identität und ihre Berechtigungen und zuletzt die Konfiguration der Anwendung. Löschen Sie die Rolle, das Verbindungsnetzwerk oder den Connector nicht manuell als allgemeine Reparaturmaßnahme. Das kann aus einer behebbaren Abweichung eine verwaiste Identität oder einen künftig fehlschlagenden Abgleich machen.

Container-Links

Ein Container-Link gibt einem Container, einem Deployment oder einem Compose-Dienst privaten Zugriff auf einen Port eines anderen Workloads, auf demselben oder einem anderen Node. Der Nutzer erreicht das Ziel als alias:port; das Ziel benötigt keinen veröffentlichten Port, und der Link öffnet nur diesen Port, in eine Richtung. Links innerhalb eines Nodes bleiben auf diesem Node; Links zwischen Nodes laufen über das Relay.

Gemeinsamer Connector und Verbindungsnetzwerke

Ab 2.11.1 betreibt jeder Docker Node einen gemeinsamen Secure-Link-Connector für alle seine Datenbank-Bindings, Speicherverbindungen und Container-Links. Es gibt keine Connector-Container pro Verbindung und keine Host-Listener. Jede Verbindung erhält ein kleines eigenes privates Netzwerk, dem der Nutzer beitritt; der Connector beantwortet dort den Alias der Verbindung.

Neue Verbindungsnetzwerke beziehen ihre Adressen aus einem eigenen Bereich, standardmäßig 10.213.x.x (ein /16), ein /26 pro Verbindung, sodass Verbindungen niemals die Adresspools aufbrauchen, die Docker Ihren eigenen Netzwerken zuweist. Netzwerke, die vor 2.11.1 erstellt wurden, behalten ihre Adressen. Der Daemon überspringt Subnetze, die bereits von Docker-Netzwerken oder den eigenen Routen des Hosts belegt sind. Überschneidet sich der Bereich mit einem Netzwerk, das der Node über seine Standardroute erreicht, etwa einem Standortnetz oder einem VPN hinter einem Router, legen Sie in der Konfigurationsdatei des Docker-Daemons, /etc/docker-daemon/config.yaml, einen anderen IPv4-Bereich der Größe /26 oder größer fest:

docker:
  secure_links:
    subnet_pool: "<IPv4 range in CIDR notation>"

Starten Sie den Docker-Daemon nach der Änderung neu. Nur neue Verbindungsnetzwerke verwenden den neuen Bereich; bestehende behalten ihren, bis ihre Verbindung neu erstellt wird.

Wenn der Connector selbst aktualisiert wird, übergibt der vorherige Connector seine offenen Verbindungen an den neuen, der sie ohne erneuten Verbindungsaufbau weiterführt. Ein Connector von vor 2.11.4 kann sie nicht übergeben: Er behält sie bis zu einer Stunde und schließt sie dann einmalig, und ein drittes Update innerhalb dieser Stunde schließt die Verbindungen des ältesten Connectors sofort.

Upstream-Verbindungen für Ingress

Routen und Additional Routes können unterstützte Docker-Ressourcen über einen Secure Link ansteuern. Opfield validiert die ausgewählte Ressource und den Anwendungsport, erstellt die Beziehung und gleicht einen Connector, der Opfield gehört, über Relay ab. Der Connector für Datenverkehr von nginx zu Workloads ist eine echte Laufzeitkomponente, bleibt aber außerhalb der gewöhnlichen APIs für den Benutzer-Lebenszyklus.

Eine Verbindung, die von einer verwalteten Route erstellt wurde, gehört dieser Route. Sie ist zur Diagnose sichtbar, kann aber nicht eigenständig gelöscht werden; das Deaktivieren der Route bewahrt ihre Konfiguration und Beziehung, während das Löschen der Route das zugehörige Binding nach dem Abgleich außer Kraft setzt. Ein Neustart oder eine Neuerstellung des Workloads erhält die Verbindung, weil die Route die stabile Opfield-Ressource ansteuert. Die Übernahme eines Deployments und Änderungen an Compose-Revisionen lösen die aktive Laufzeit hinter derselben übergeordneten Identität auf.

In 2.11 nehmen die Secure-Link-Listener auf einem Ingress Node auch unter Last weiter Verbindungen an. Zuvor, ab 2.10.0, prüfte der nginx-Daemon jede neue Verbindung mit einem vollständigen Dump der nginx-Konfiguration, sodass ein Ingress Node ab etwa 100 neuen Secure-Link-Verbindungen pro Sekunde ins Stocken geriet und noch lange nach dem Abklingen der Last Anfragen fehlschlagen ließ. Jetzt verwendet die Prüfung zwischengespeicherte Prozessinformationen: Ein Ingress Node mit einem Kern bewältigt Tausende neuer Verbindungen pro Sekunde, Verbindungen über 1024 im Aufbau werden sofort abgelehnt, damit nginx schnell auf einen anderen Weg ausweicht, statt sie einzureihen, Verbindungen, die ein Client bereits aufgegeben hat, werden verworfen, ohne einen Tunnel zu öffnen, und der Listener erholt sich, sobald die Last sinkt. Ein vorübergehender Annahmefehler, etwa das Ausgehen von Dateideskriptoren, stoppt einen Listener nicht mehr bis zum Neustart des Daemons.

Erweiterte nginx-Konfigurationen können separat verwaltete zusätzliche Bindings mit eigenem Lebenszyklus verwenden. Verwechseln Sie diese nicht mit Bindings, die einer Route gehören. Ermitteln Sie vor dem Löschen eines benutzerverwalteten Bindings jede Konfiguration, die darauf verweist.

Normaler Ablauf und Prüfung

Wählen Sie für einen Ingress-Upstream das verwaltete Ziel im Editor der Route oder Additional Route, wählen Sie den Dienst- oder Anwendungsport und das Protokoll, speichern Sie und warten Sie sowohl auf den Abgleich des Secure Links als auch auf die Validierung der nginx-Konfiguration. Prüfen Sie dann die Zielidentität, den Zustand des Connectors, den Health-Zustand der Route und eine echte externe Anfrage.

Erstellen Sie bei einer verwalteten Datenbank das Binding vom geeigneten Workload und der Datenbank aus, wählen Sie Zugriff mit minimalen Rechten, warten Sie auf die Engine-Identität und die Verbindung, wenden Sie bei Bedarf die Workload-Konfiguration an und führen Sie eine echte Anwendungsabfrage aus. Bestätigen Sie die Telemetrie des Bindings sowie die Logs von Workload und Datenbank.

Die Prüfung sollte den vorgesehenen Pfad nachweisen und nicht nur die Existenz eines Eintrags. Prüfen Sie bei Ingress die Verfügbarkeit von Relay, beide Node-Verbindungen, die Aufbaulatenz, aktive Datenströme, den Durchsatz, den Zustand beim Abschluss, Zulassungsablehnungen, nginx-Logs und das Verhalten der Anwendung. Prüfen Sie bei Datenbank-Bindings die Bereitschaft der Datenbank, den Abgleich der Verbindung, den Zustand des Engine-Prinzipals, die Konnektivität der Anwendung und die aktuelle Workload-Konfiguration.

Was Secure Links nicht leisten

• Sie sind kein universelles VPN und kein Overlay-Netzwerk.
• Sie bieten keine beliebige TCP- oder SSH-Weiterleitung.
• Sie öffnen Host-Firewalls nicht automatisch.
• Sie ersetzen keine Authentifizierung auf Anwendungsebene, wo das Zielprotokoll sie verlangt.

Sie übertragen auch nicht die Zuständigkeit für die Zielressource, machen nicht unterstützte Workloads nicht portierbar und autorisieren keinen Benutzer, dem der Zugriff auf eine der beiden Seiten fehlt. Ein Secure Link ist kein Grund, Steuerungsschnittstellen von Daemons, Ports des Datenbankbesitzers oder interne Zugangsdaten von Connectoren offenzulegen.

Fehler und sichere Wiederherstellung

Wenn eine Ingress-Route gespeichert wird, der Datenverkehr aber fehlschlägt, prüfen Sie, ob die Route aktiviert ist und ob Wartung aktiv ist, die nginx-Revision, Relay, die Konnektivität der Ingress- und Docker-Nodes, Laufzeit und Port des Ziels, die Zulassung durch den Connector und dann die Anwendungslogs und das Protokollverhalten. Veröffentlichen Sie keinen internen Workload-Port als undokumentierte Umgehung.

Stellen Sie bei einer Unterbrechung eines Nodes oder von Relay die Konnektivität wieder her und warten Sie auf frische Fähigkeitsmeldungen und den Abgleich des Sollzustands, bevor Sie Identitäten ersetzen. Bewahren Sie Operationsverlauf und Request-IDs. Wird ein Löschvorgang unterbrochen, behalten Sie den dauerhaften Eintrag des Eigentümers oder Bindings bei, damit Opfield die Bereinigung abschließen kann. Das manuelle Löschen von Connectoren, Netzwerken oder Engine-Prinzipalen, die Opfield gehören, ist eine außergewöhnliche Wiederherstellungsmaßnahme, die ein abgestimmtes Verfahren erfordert, und keine erste Reaktion.