Argumente erstellen: Komfort, der die Sicherheit gefährden kann
Docker-Build-Argumente erleichtern das Übergeben von Konfigurationswerten während des Build-Prozesses, haben aber einen oft übersehenen Nachteil: Diese Argumente bleiben in den Metadaten und Ebenen des Images erhalten. Entwickler gehen häufig davon aus, dass diese Werte nach dem Build verschwinden, doch tatsächlich betten die Docker-Build-Argumente sie in die Docker-Image-Historie ein.
⚠️Unsicheres Beispiel, nur zu Schulungszwecken. Nicht in der Produktion verwenden.
Jeder, der kandidiert Docker-Geschichte or Docker inspizieren werde die finden API-SCHLÜSSEL Der Wert ist in den Metadaten des Images eingebettet. Dies geschieht aufgrund der Docker-Build-Anweisung für das Build-Argument. commitwird jeder Bauschritt als permanente Schicht betrachtet.
Sichere Version:
Pädagogischer Hinweis: Vermeiden Sie das Einschleusen von Geheimnissen über Docker-Build-Argumente. Verwenden Sie -Geheimnis Die von BuildKit bereitgestellten Mounts für sensible Daten werden niemals in Layern oder Metadaten gespeichert.
Wie Geheimnisse in Schichten und Metadaten fortbestehen
Jede Anweisung in einer Dockerfile erzeugt eine neue Image-Ebene. Selbst wenn Sie Dateien überschreiben oder löschen, bleiben frühere Ebenen im Cache erhalten. Aus diesem Grund bleiben Geheimnisse, die mit Docker-Build-Argumenten oder Docker-Build-Argumenten injiziert werden, unbegrenzt erhalten.
⚠️Unsicheres Beispiel, nur zu Schulungszwecken. Nicht in der Produktion verwenden.
Die Verwendung von ARG Auf diese Weise wird das Token in die Bildebene eingebettet und ist sichtbar durch Docker-Image untersuchen oder aus dem Cache extrahiert. Sichere Version:
Pädagogischer Hinweis: Bei dieser Methode bleiben sensible Werte im Verlauf erhalten. Verwenden Sie stattdessen temporäre geheime Mounts, um Token und Anmeldeinformationen zu schützen.
Häufige Fehlkonfigurationen in CI/CD Pipelines
In modern pipelinesEntwickler geben Geheimnisse oft weiter CI/CD Umgebungen, die Docker-Argumente oder gemeinsam genutzte Caches verwenden. Diese Vorgehensweise führt dazu, dass Geheimnisse in Protokollen, Runnern und Registry-Caches preisgegeben werden. Mit gemeinsamen Läufern in GitHub-Aktionen, GitLab CI oder JenkinsDiese Geheimnisse können sich leicht auf branchenfremde Bereiche ausbreiten.
⚠️Unsicheres Beispiel, nur zu Schulungszwecken. Nicht in der Produktion verwenden.
Das Geheimnis landet in Build-Protokollen und Image-Metadaten und verstößt damit gegen das Prinzip der minimalen Rechtevergabe. Sichere Version:
Pädagogischer Hinweis: Vermeiden –build-arg für Geheimnisse. In CI/CDGeheimnisse sollten niemals über Umgebungsvariablen oder Protokolldateien weitergegeben werden. Verwenden Sie stattdessen immer temporäre Geheimnis-Mounts.
Bewährte Verfahren zur Verhinderung der Offenlegung von Geheimnissen
Die Verhinderung der Offenlegung von Geheimnissen beginnt mit der Erkenntnis, dass Docker-Build-Argumente systembedingt öffentlich sind. Sie eignen sich hervorragend für Konfigurationen (wie Versions-Tags oder Feature-Flags), aber nicht für Zugangsdaten.
Praxisbeispiele
- Verwenden Sie BuildKit. - Geheimnis für sensible Daten.
- Geheimnisse sollten niemals über ARG oder ENV definiert werden.
- Speichern .env, Geheimnisse/ und config / Verzeichnisse zu .dockerignore.
- Mehrstufige Builds anwenden um private Bühnen zu isolieren.
- Caches leeren nach sensiblen Aufbauphasen.
- Bildmetadaten validieren mit Docker-Verlauf vor der Veröffentlichung.
Mini-Checkliste zur Prävention
- Alle Dockerfiles prüfen Docker-Build-Argumente Verwendung.
- Ersetzen Sie die Anmeldeinformationen durch BuildKit. -Geheimnis.
- Gewährleisten .dockerignore Sensible Dateien werden ausgeschlossen.
- Desinfizieren CI/CD Umgebungsvariablen.
- Automatisierte Geheimscans vor dem Hochladen von Bildern.
Pädagogischer Hinweis: Wird ein Wert über ein Docker-Build-Argument übergeben, wird er dauerhaft gespeichert. Verwenden Sie Secret Mounts und isolierte Build-Phasen, um sensible Daten zu schützen.
Erkennung unsicherer Verwendung von Build-Argumenten vor der Bereitstellung
Automatisierte Scans sind unerlässlich, um riskante Docker-Build-Argumentmuster zu identifizieren, bevor ein Image in die Produktion übertragen wird. Tools wie Wissenswertes, Hadolint und Xygeni kann in Dockerfiles oder Image-Layern eingebettete Anmeldeinformationen erkennen.
Funktionales Code-Snippet mit Kontext und Kontrollmechanismen
Dieser Schritt dient als Präventivmaßnahme und blockiert unsichere Docker-Befehle für Build-Argumente vor der Bereitstellung.
Pädagogischer Hinweis: Dockerfile-Scanning als obligatorische Funktion integrieren CI/CD Phase. Automatisierte Tools helfen dabei, eine einheitliche und sichere Build-Hygiene zu gewährleisten.
Wie Xygeni vor Geheimnislecks während der Build-Phase schützt
Xygeni Secrets Security Bietet eine spezielle Erkennung für den Missbrauch von Docker-Argumenten. Es identifiziert unsichere ARG-Definitionen, verfolgt geheime Werte über verschiedene Build-Phasen hinweg und kennzeichnet verbleibende Anmeldeinformationen in Image-Metadaten oder zwischengespeicherten Ebenen. Durch die Integration mit Ihrem CI/CD pipelineEs setzt die Sicherheitsrichtlinien für Docker-Build-Argumente vor Zusammenführungen oder Veröffentlichungen durch.
Funktionsausschnitt, Beispiel für kontextbezogene Durchsetzung
Fügen Sie diesen Job Ihrer Liste hinzu pipelineValidierungsphase für kontinuierlichen Schutz.
Pädagogischer Hinweis: Xygeni erzwingt automatisch sichere Docker-Praktiken und verhindert so, dass riskante Build-Zeit-Konfigurationen Geheimnisse zwischen verschiedenen Umgebungen preisgeben.
Fazit: Docker sollte niemals Geheimnisse verarbeiten.
Docker-Build-Argumente sind ein zweischneidiges Schwert: praktisch für die Konfiguration, riskant für Geheimnisse. Jeder Docker-Build-Wert, den Sie einfügen, kann in Metadaten, Image-Historie oder Caches gespeichert werden.
Schützen Sie Ihre Builds durch:
- Verwendung von BuildKit -Geheimnis für Anmeldeinformationen.
- Isolierung sensibler Daten in mehrstufigen Builds.
- Vor der Bereitstellung wird auf durchgesickerte Werte gescannt.
- Durchsetzung von Sicherheitsrichtlinien durch Xygeni Code Security.
Ihr Build pipeline Die Sicherheit hängt allein von den Geheimnissen ab, die Sie nicht preisgeben. Behandeln Sie jedes Build-Argument eines Docker-Builds als potenzielles Einfallstor für Informationen und schützen Sie es, bevor Angreifer es entdecken.
