Garder les identifiants proxy de build hors des images Docker

Pour télécharger des paquets pendant un build, utilisez les entrées proxy prédéfinies de Docker au lieu d’enregistrer une route temporaire dans ENV du Dockerfile. Un appel POSIX peut fournir :

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 .

Remplacez le point de terminaison de la documentation. Si aucune valeur ne suit les noms de --build-arg, elles viennent de l’environnement de cet appel. Ces entrées prédéfinies ne nécessitent pas de déclarations ARG correspondantes.

Docker exclut par défaut ces arguments proxy de la gestion du cache de build et de docker history. Les référencer explicitement dans le Dockerfile modifie ce comportement ; n’ajoutez donc pas de déclarations simplement parce qu’un autre exemple d’argument de build le fait.

Le processus reçoit tout de même les valeurs. Une URL authentifiée peut fuiter par l’environnement affiché, les journaux, une configuration copiée ou des opérations ultérieures sur l’image, même si une vue de l’historique la masque. ENV dans le Dockerfile fait de la route une partie de l’environnement final de l’image et peut rendre un proxy réservé au build dépendance de chaque conteneur.

Lorsqu’une commande a besoin de données sensibles, les montages de secrets BuildKit fournissent une interface de secret limitée au build. Limitez l’identifiant à cette opération ; n’affichez pas le montage et ne copiez pas son contenu dans une couche de l’image.

Ces entrées de build ne configurent ni le pull du registre effectué plus tôt par le daemon ni la route d’un hôte de build distant inaccessible. Ensuite, inspectez l’image finale visée et la configuration de l’application pour repérer les valeurs proxy persistantes, sans supposer que le traitement temporaire a supprimé toutes les copies.