Secrets de build

Certains builds ont besoin d'un identifiant : un jeton de registre privé, une clé SSH. Les secrets de BuildKit le donnent à un seul RUN, sans l'écrire dans aucune couche, aucun historique ni aucune clé de cache.

Comment ça marche

RUN --mount=type=secret,id=npm_token,env=NPM_TOKEN met le secret dans une variable de cette seule commande (ou dans un fichier, /run/secrets/<id> par défaut). docker build --secret id=npm_token,env=NPM_TOKEN le fournit ; dans Compose, build: secrets: dans le service et une entrée secrets: de premier niveau avec file: ou environment:.

Ce qui casse

Les valeurs de ARG et ENV finissent dans l'historique et la configuration de l'image, visibles avec docker history et docker inspect, et les vérifications de build de Docker les signalent (SecretsUsedInArgOrEnv). Un fichier copié puis supprimé par une étape suivante reste dans la couche qui l'a copié. Un build multi-étapes cache la valeur de l'image finale, pas du cache de build.

Dans un Dockerfile

# syntax=docker/dockerfile:1
FROM node:20-alpine
WORKDIR /app
COPY package*.json .npmrc ./
RUN --mount=type=secret,id=npm_token,env=NPM_TOKEN npm ci --omit=dev

Regarde-le casser, puis répare-le

Écris le Dockerfile ou le fichier compose, tape les commandes docker, et regarde un serveur simulé les exécuter à travers redémarrages, mises à jour et trafic. Gratuit pour commencer.

Ouvrir le parcours Ouvrir le bac à sable