Build-Zeit-Proxy-Zugangsdaten aus Docker-Images heraushalten

Verwenden Sie für Paketdownloads während eines Builds Dockers vordefinierte Proxy-Eingaben, statt eine vorübergehende Route in Dockerfile-ENV zu speichern. Ein POSIX-Aufruf kann Folgendes liefern:

HTTP_PROXY=http://203.0.113.10:8080 \
HTTPS_PROXY=http://203.0.113.10:8080 \
docker build --build-arg HTTP_PROXY --build-arg HTTPS_PROXY .

Ersetzen Sie den Dokumentationsendpunkt. Werden nach den Namen von --build-arg keine Werte angegeben, stammen sie aus der Umgebung dieses Aufrufs. Für diese vordefinierten Eingaben sind keine passenden ARG-Deklarationen erforderlich.

Docker schließt diese Proxyargumente standardmäßig aus der Build-Cache-Verarbeitung und aus docker history aus. Eine ausdrückliche Referenz im Dockerfile ändert dieses Verhalten. Fügen Sie daher keine Deklarationen nur deshalb hinzu, weil ein anderes Build-Argument-Beispiel dies tut.

Der Prozess erhält die Werte trotzdem. Eine authentifizierte URL kann über ausgegebene Umgebungsdaten, Logs, kopierte Konfiguration oder spätere Image-Operationen entweichen, auch wenn eine History-Ansicht sie ausblendet. Dockerfile-ENV macht eine Route zu einem Teil der endgültigen Image-Umgebung und kann einen reinen Build-Proxy zur Abhängigkeit jedes Containers machen.

Wenn ein Befehl geheime Daten benötigt, bieten BuildKit-Secret-Mounts eine Schnittstelle für Build-Geheimnisse. Beschränken Sie die Zugangsdaten auf diesen Vorgang; geben Sie den Mount nicht aus und kopieren Sie seinen Inhalt nicht in eine Image-Schicht.

Diese Eingaben konfigurieren weder den früheren Registry-Pull des Daemons noch die Hostroute eines nicht erreichbaren Remote-Builders. Prüfen Sie anschließend das vorgesehene endgültige Image und die Anwendungskonfiguration auf dauerhafte Proxywerte, statt anzunehmen, die temporäre Eingabe habe jede Kopie entfernt.