Exponierte Container-Registry

Was ist Exponierte Container-Registry?

A registry that allows anonymous pull hands your source, your config and your deployed artifact to anyone who guesses the repository name. Anonymous push lets an attacker overwrite the tag you are about to ship, and the pipeline notices nothing. You'll pull a production image, rebuild it with an implant, push it back under the same release tag, and task that implant inside the running service. Then you'll require authentication, scope push, mark release tags immutable, and see why the deployed digest, not the tag, is what to check.

Was Sie lernen in Exponierte Container-Registry

• Erkennen Sie, dass anonymer Pull bei einem privaten Repository Quellcode, Konfiguration und Build-Schichten an Angreifer weitergeben kann
• Führen Sie eine manipulierte Bereitstellung auf einen Angreifer zurück, der das Produktions-Image mit einer Hintertür neu baute und unter demselben Release-Tag pushte
• Konfigurieren Sie die Registry-Richtlinie so, dass Pull eine Anmeldung erfordert und Push nur auf Repositories erlaubt ist, für die die Pipeline zuständig ist
• Machen Sie Release-Tags unveränderlich, damit ein vorhandener Tag nicht auf ungeprüfte Inhalte umgehängt werden kann
• Explain why a deployed image is checked by comparing its digest against the digest the pipeline recorded, since a tag moves but a digest cannot

Exponierte Container-Registry — Trainingsschritte

1. Nach einem öffentlich zugänglichen Repository suchen

   Bob sucht nicht gezielt nach Quenmoor. Er scannt selbst betriebene Registries, die ohne Anmeldung antworten, und listet deren Repositories auf. Quenmoors Registry antwortet; ein Repository ist dabei besonders interessant.

2. Ein versehentlich offenes privates Repository

   Bob sucht in selbst betriebenen Registries nach Repositories, auf die er keinen Zugriff haben sollte. Quenmoors Registry antwortete ohne Anmeldung. Besonders interessant ist ein interner Dispatch-Dienst.

3. Öffentlich lesbar und beschreibbar

   Der Dienst ist intern, aber seine Zugriffsregeln sind weit geöffnet. Bob prüft die beiden entscheidenden Einstellungen.

4. Das Image anonym herunterladen

   Bob braucht weder Zugangsdaten noch eine Mitgliedschaft oder Zugriffsfreigabe. Er lädt das Produktions-Image direkt aus der Registry herunter.

5. Die Produktionskonfiguration auslesen

   Das Image enthält nicht nur Code, sondern auch die fest in eine Schicht eingebaute Produktionskonfiguration. Bob startet daraus einen Container und liest die Datei.

6. Das Image mit einer Hintertür neu bauen

   Das Auslesen des Images war Datendiebstahl; sein Ersetzen verschafft Bob Kontrolle. Er verwendet das echte Produktions-Image als Grundlage und fügt beim Neubau eine einzige Schicht hinzu. Dazu dient dieses Dockerfile.

7. Die hinzugefügte Schicht

   Der Rest ist Quenmoors unverändertes Image. Eine einzige RUN-Anweisung baut einen dauerhaften Zugang ein, der bei jeder Bereitstellung mitgeliefert wird.

8. Als Produktions-Release taggen

   Bob baut das manipulierte Image und versieht es mit genau dem Namen und Tag, von dem Quenmoor seine Produktion bereitstellt. So erscheint es der Registry als Produktions-Release.

9. Ein manipuliertes Image auf den Tag pushen

   Das Lesen des Images war Datendiebstahl. Nun baut Bob es mit einer Hintertür im Entrypoint neu und pusht es auf genau den Tag, von dem Quenmoor bereitstellt. Die Registry nimmt den Push ohne Identitätsprüfung an.

10. Was Bob durch den Push gewann

    Die nächste Bereitstellung brachte Bobs Image in die Produktion. Seine zusätzliche Schicht meldete sich aus dem laufenden Dienst bei ihm. Bob muss nicht mehr von außen in Quenmoors Systeme eindringen: Sein Code läuft im Dienst.