Registries und Image-Vertrauen

Registries liefern die Images, die Docker Nodes ausführen, und nehmen die Artefakte auf, die Build Worker veröffentlichen. Opfield hält Registry-Zugangsdaten und Zugriffsentscheidungen getrennt von der Workload-Konfiguration, die ein Image verwendet. Diese Trennung erlaubt es einem Operator, den Registry-Zugriff zu rotieren, ohne ein Passwort in einem Container, einem Deployment oder einer Quelldefinition offenzulegen.

Die Richtlinie für Image-Vertrauen festlegen

Die entscheidende Frage ist nicht nur, wo ein Image gespeichert ist, sondern welche Belege erforderlich sind, bevor es ausgeführt werden darf. Eine praktikable Richtlinie benennt freigegebene Registries, erforderliche unveränderliche Digests, wer veröffentlichen darf, den Schwachstellen-Schwellenwert, die Verantwortlichen für Zugangsdaten und wie lange Rollback-Artefakte aufbewahrt werden.

Anwendungsteams wählen das Software-Artefakt. Sicherheitsverantwortliche legen Zulassung und Geltungsbereich von Zugangsdaten fest. Plattformverantwortliche pflegen die Verfügbarkeit der Registry und den Zugriff der Ziel-Nodes. Opfield erfasst Zuordnungen, Secrets, Build-Herkunft und Richtlinienergebnisse, macht ein unbekanntes Image aber nicht schon deshalb vertrauenswürdig, weil ein Pull gelungen ist.

Erfolg bedeutet, dass der bereitgestellte Workload den geprüften Digest verwendet, jeder benötigte Node ihn über einen freigegebenen Weg für Zugangsdaten beziehen kann und das vorherige bekannt fehlerfreie Artefakt für das Rollback-Fenster verfügbar bleibt.

Vertrauenswürdigen Zugriff konfigurieren

Speichern Sie Zugangsdaten privater Registries in Opfield und beschränken Sie sie auf den vorgesehenen Build- oder Laufzeitpfad. Konfigurieren Sie einen separaten vertrauenswürdigen Origin für einen Token-Dienst nur dann, wenn die Registry die Bearer-Authentifizierung bewusst an diesen Dienst delegiert. Bestätigen Sie vor einem Produktions-Rollout den Registry-Endpunkt, den Repository-Zugriff und das Zertifikatsvertrauen.

Legen Sie Registry-Passwörter niemals in Image-Referenzen, Git-URLs, Build-Argumente, Logs, Archivnamen oder Screenshots. Schlägt die Authentifizierung fehl, diagnostizieren Sie die Registry-Zugangsdaten, die Repository-Berechtigung, die Konfiguration des Token-Dienstes und die Erreichbarkeit vom Ziel-Node aus, statt den Workload wiederholt neu zu starten.

Verhalten der internen Registry

Die interne Distribution-Registry von Opfield speichert freigegebene Build-Artefakte per unveränderlichem Digest. Sie behält Artefakte, die von aktiven Workloads, Rollback-Slots, laufenden Operationen, angehefteten Referenzen und kürzlich erfolgreichen Builds benötigt werden. Für die interne Nutzung durch Opfield benötigt sie keine öffentliche Domain. Die Registry meldet den tatsächlich von ihrem Volume belegten Speicher, aktualisiert etwa alle 10 Minuten.

Dass ein Image in der internen Registry vorhanden ist, macht es nicht zu einem öffentlichen Release. Ein Workload muss weiterhin so konfiguriert sein, dass er den Digest verwendet, ihn erfolgreich auf seinem Ziel-Node bezieht und seine betriebliche Prüfung besteht.

Optionaler externer Zugriff für Docker-Clients

Externer Zugriff für Docker-Clients ist ein eigener Leistungsumfang und eine eigene Ingress-Konfiguration und funktioniert auf Standard-nginx-Ingress-Nodes. Er erfordert eine ausgewählte nginx-Platzierung, eine Domain, ein TLS-Zertifikat und ein auf Repository oder Aktion beschränktes Token. Nach dem Ende einer Lizenz-Kulanzfrist bleiben der externe Einstiegspunkt und seine Einstellungen erhalten, aber der Token-Endpunkt stellt keine neuen Tokens aus, bis der Tarif verlängert wird. Jede Token-Anfrage prüft die aktuelle Autorisierung und den Leistungsumfang erneut, sodass ein Widerruf von beidem für den nachfolgenden Zugriff wirksam wird.

Aktivieren Sie den externen Zugriff nur, wenn ein echter Client-Ablauf ihn erfordert. Prüfen Sie TLS, Authentifizierung und die minimalen Repository- bzw. Aktionsberechtigungen mit einem Client außerhalb der Produktion, bevor Sie sich für die Automatisierung darauf verlassen. Das Entfernen der Ingress-Konfiguration beendet den Client-Zugriff, löscht aber keine intern aufbewahrten Artefakte.

Hinweise zu Vorfällen und Bereinigung

Bestätigen Sie bei einem fehlgeschlagenen Pull zuerst den genauen Image-Digest, die Registry-Zuordnung, den Geltungsbereich der Zugangsdaten und den Netzwerkpfad des Nodes. Vergleichen Sie bei einem unerwarteten Image seinen Digest mit dem freigegebenen Build-Eintrag, statt einem Tag zu vertrauen. Ermitteln Sie vor dem Entfernen einer Registry-Konfiguration die Workloads und Rollback-Kandidaten, die sie noch benötigen; stellen Sie diese zuerst auf eine freigegebene Alternative um.

Lebenszyklus von Zugangsdaten

Bevorzugen Sie auf Repository und Aktion beschränkte Zugangsdaten gegenüber breiten Administrations-Tokens für Registries. Halten Sie für jede Zugangsberechtigung einen Verantwortlichen und einen Rotationsprozess fest und testen Sie den Ersatz, bevor Sie den alten Wert widerrufen, wenn kontinuierliche Auslieferung davon abhängt. Ein Widerruf muss Build Worker, Docker Nodes und externe Clients getrennt berücksichtigen, da sie unterschiedliche Zugriffswege verwenden können.

Wird eine Zugangsberechtigung offengelegt, widerrufen Sie sie bei der Registry, ersetzen Sie sie in Opfield und ermitteln Sie Builds oder Pulls, die während des Offenlegungszeitraums ausgeführt wurden. Nur die Kopie in Opfield zu rotieren, macht das ursprüngliche Secret beim Anbieter nicht ungültig. Prüfen Sie die Logs auf unerwartete Repositories oder Digests, ohne Header mit Secrets in den Vorfalleintrag zu kopieren.

Details für Betreiber: Pull-Fehler und Aufbewahrung

Trennen Sie bei Authentifizierungsfehlern Erreichbarkeit über DNS/TLS, Registry-Zuordnung, Ablehnung der Zugangsdaten, Origin des Token-Dienstes, Repository-Berechtigung und fehlendes Manifest. Testen Sie das genaue Repository und den genauen Digest vom betroffenen Ausführungspfad aus statt von einem unbeteiligten Administrator-Arbeitsplatz.

Ermitteln Sie vor einem Prune der internen Registry oder dem Entfernen des externen Zugriffs aktive Workload-Digests, Rollback-Slots von Deployments, laufende Builds, angeheftete Artefakte und kürzlich bekannt fehlerfreie Releases. Wurde ein benötigtes Artefakt entfernt, veröffentlichen Sie es erneut oder bauen Sie es aus der geprüften Quellrevision neu, bevor Sie den Workload ändern. Ersetzen Sie es nicht durch einen ungeprüften Tag, der zufällig denselben Namen hat.