Sichere Upstreams

Ein sicherer Upstream lässt eine öffentliche Route einen privaten verwalteten Workload erreichen, ohne den Host-Port des Workloads zu veröffentlichen. Ein Secure Link ist der authentifizierte private Transport von Opfield zwischen der Ingress-Seite und der Workload-Seite über Relay. Der Workload behält keinen offenen Host-Port, und die Route folgt der verwalteten Identität des Workloads über Neustarts und Neuerstellungen hinweg.

Verwenden Sie ihn, wenn die Anwendung nur über den Opfield-Ingress öffentlich sein soll. Authentifizierung und Health-Zustand der Anwendung bleiben bei der Anwendung. Die Einrichtung ist abgeschlossen, wenn der Workload keinen unnötigen öffentlichen Port hat, der Link bereit ist und eine echte Anfrage über den kanonischen Hostnamen gelingt.

Wählen Sie im Editor der Route oder Additional Route ein verwaltetes Docker-Ziel. Opfield validiert die Zuständigkeit für den Workload, Ihren Zugriff auf das Docker-Ziel und den ausgewählten Dienst bzw. Port, erstellt den Secure Link der Route und gleicht den Connector-Zustand über das Relay ab.

Bindings einer Route folgen dem Lebenszyklus der Route. Sie können geprüft, aber nicht eigenständig gelöscht werden. Zusätzliche benutzerverwaltete Bindings sind für erweiterte nginx-Konfigurationen gedacht und haben einen eigenen Lebenszyklus.

Ein zusätzliches Binding kann auch bereiten verwalteten Objektspeicher (Managed S3 storage) ansteuern: privates S3 über das Relay, ohne gemeinsames Docker-Netzwerk und ohne veröffentlichten S3-Port. Clients benötigen weiterhin S3-Zugangsdaten. Referenzieren Sie es in der erweiterten Konfiguration als {{additionalSecureLinks.<name>}}, was das Schema bereits enthält, zum Beispiel proxy_pass {{additionalSecureLinks.<name>}};; ein Binding, auf das die erweiterte Konfiguration noch verweist, kann nicht gelöscht werden. Das Erstellen erfordert Bearbeitungszugriff auf die Route und Lesezugriff auf den Speicher, und verwalteter Speicher kann nicht der Haupt-Upstream einer Route sein.

Prüfen Sie den Zustand des Connectors, den Health-Zustand der Route und das Verhalten der Anwendung. Wird ein Workload neu erstellt, verbindet Opfield den Link über die stabile Ressourcenidentität neu. Wird eine Route gelöscht, setzt Opfield ihr Binding außer Kraft.

Umgehen Sie einen fehlgeschlagenen Link nicht durch Veröffentlichen eines internen Workload-Ports, bevor Sie den Fehler verstanden haben. Prüfen Sie zuerst den Zustand von Relay, beide Node-Verbindungen, die Zielidentität, die Autorisierung des Scopes und die Connector-Logs.

Voraussetzungen

• Die Ingress- und Docker-Nodes sind online und mit dem aktuellen Relay-Vertrag kompatibel.
• Der Ziel-Container, das Deployment oder der Compose-Dienst gehört Opfield und hat eine stabile Ressourcenidentität.
• Der ausgewählte Anwendungsport ist der Port, auf dem der Prozess tatsächlich lauscht, und kein unbeteiligter veröffentlichter Host-Port.
• Der Aufrufer kann das Ziel lesen und die Route ändern.
• Relay ist fehlerfrei, und beide Nodes können ihren zugewiesenen Relay-Endpunkt erreichen.

Einen verwalteten Upstream erstellen

1. Öffnen Sie den Editor der Route oder Additional Route.
2. Wählen Sie den Zieltyp „verwaltetes Docker-Ziel“.
3. Wählen Sie Node und Ressource, statt eine flüchtige Containeradresse einzutippen.
4. Wählen Sie den Dienst- oder Anwendungsport und das Protokoll. Mit einem Docker-Daemon von 2.11 füllt der Dialog den Port aus, auf dem der Container tatsächlich lauscht, auch bei Images, die keinen Port deklarieren (kein EXPOSE); ältere Daemons bieten nur die deklarierten Ports an.
5. Speichern Sie die Route und warten Sie sowohl auf den Abgleich des Secure Links als auch auf die Validierung der nginx-Konfiguration.
6. Prüfen Sie das Ziel-Abzeichen, die Telemetrie unter Link Runtime, den Health-Zustand der Route und eine externe Anfrage.

Der Connector-Container für Datenverkehr von nginx zu Workloads gehört Opfield. Er ist für gewöhnliche Lebenszyklusoperationen ausgeblendet und wird mit Relay ausgeliefert. Das Neuerstellen des Anwendungs-Workloads darf die Zuständigkeit für diesen Connector nicht übertragen und keine neue Route erfordern.

Verhalten im Lebenszyklus

• Ein Neustart oder eine Neuerstellung des Workloads erhält den Link, weil die Route die stabile Opfield-Ressource ansteuert.
• Die Übernahme eines Deployments aktualisiert den aktiven Workload hinter derselben Deployment-Identität.
• Das Anwenden von Compose löst den ausgewählten Dienst aus der aktiven Projektrevision auf.
• Das Deaktivieren einer Route beendet ihre Auslieferung, bewahrt aber ihre Konfiguration und die eigene Beziehung.
• Das Löschen einer Route setzt ihr Binding nach dem Abgleich außer Kraft.
• Ein benutzerverwaltetes zusätzliches Binding hat einen unabhängigen Lebenszyklus und muss ausdrücklich entfernt werden. Das Löschen wird abgelehnt, solange die erweiterte oder rohe Konfiguration der Route oder die erweiterte Konfiguration einer Additional Route noch darauf verweist, sei es über ihre Variable {{additionalSecureLinks.<name>}} oder über ihren gerenderten Upstream-Namen.

Fehlerdiagnose

Wenn die Route gespeichert wird, der Datenverkehr aber fehlschlägt, prüfen Sie in dieser Reihenfolge:

1. Route aktiviert und nicht in Wartung;
2. Revision der nginx-Konfiguration angewendet;
3. Verfügbarkeit von Relay;
4. Konnektivität der Ingress- und Docker-Nodes;
5. Laufzeitzustand der Zielressource und ausgewählter Port;
6. Zustand des Secure-Link-Connectors und Zulassungsfehler;
7. Anwendungslogs und Protokollverhalten.

Veröffentlichen Sie einen Host-Port nur, wenn öffentlicher oder direkter Zugriff selbst eine Produktanforderung ist, nicht als undokumentierten Wiederherstellungsmechanismus.

Auswirkungen auf Sicherheit und Zuständigkeit

Ein verwalteter Upstream vermeidet es, den Workload auf einem gewöhnlichen Host-Port offenzulegen, macht die Anwendung aber nicht automatisch vertrauenswürdig. Die Route legt weiterhin die öffentliche Anfragegrenze fest, nginx terminiert oder leitet weiterhin das ausgewählte Protokoll weiter, und die Anwendung muss Anfragen authentifizieren, wo ihr Produktvertrag es verlangt. Secure Link schützt den privaten Transport und die Zielauswahl; er ist keine Autorisierungsschicht der Anwendung.

Der generierte Connector und seine Zugangsdaten gehören Opfield. Operatoren sollten diesen Connector nicht über gewöhnliche Docker-Lebenszyklus-APIs neu erstellen, umbenennen, sich daran anhängen oder ihn verwenden. Zugriff auf die Workload-Ressource gewährt keine Zuständigkeit für die Transportressource. Diese Trennung verhindert, dass ein Workload-Operator ein Connector-Image austauscht oder Transportmaterial liest, das der Control Plane gehört.

Vergeben Sie an Benutzer nur die Routen- und Workload-Scopes, die sie für ihre Aufgabe benötigen. Wer sowohl die öffentliche Route als auch den Ziel-Workload ändern kann, kann Produktionsverkehr umleiten, selbst ohne direkten Zugriff auf die Interna des Connectors; behandeln Sie diese kombinierte Berechtigung daher als Befugnis für Produktions-Deployments.

Vorgehen bei Änderungen und Wiederherstellung

Halten Sie vor dem Neuerstellen oder Übernehmen eines Ziels die Route, die ausgewählte stabile Ressource, den Anwendungsport und den aktuellen Zustand des Links fest. Führen Sie die Workload-Operation über ihren Eigentümer aus, warten Sie, bis die neue Laufzeit bereit ist, und bestätigen Sie dann, dass der Secure Link auf dieselbe stabile Identität abgeglichen wurde. Prüfen Sie eine externe Anfrage; ein grünes Workload-Abzeichen allein beweist nicht, dass der Routenpfad funktioniert.

Bleibt der Abgleich fehlgeschlagen, obwohl beide Nodes und Relay fehlerfrei sind, bewahren Sie die fehlgeschlagene Operation und die Connector-Logs und wiederholen Sie dann die unterstützte Abgleichsaktion. Das Neuerstellen der Route ist der letzte Ausweg, weil es die Zuständigkeit ändert und nützlichen Verlauf entfernt. Muss Kundenverkehr während der Reparatur nicht verfügbar bleiben, verwenden Sie den Wartungsmodus, statt den privaten Port zu veröffentlichen.