Воспроизводимые сборки: SOURCE_DATE_EPOCH, базы запиненные по дайджесту и почему пляшущий дайджест слоя ломает подпись

Что значит «воспроизводимая» и почему дайджесты пляшут

Если команда подписывает релизные образы, задай себе вопрос: можешь ли ты прямо сейчас пересобрать тот же дайджест из тегированного коммита? Если нет — подпись доказывает меньше, чем кажется. Воспроизводимая значит: те же исходники, собранные где угодно и в любой день, дают образ с теми же дайджестами слоёв до байта. Поскольку всё в OCI контентно-адресуемо, единственный отличающийся байт где угодно в tarball-е слоя меняет sha256 этого слоя и каждый дайджест выше. Три обычных подозреваемых впрыскивают эти отличающиеся байты:

• Встроенные таймстампы. BUILD_TIME=$(date), build-info-файл с текущим временем или компилятор, штампующий дату сборки — любое пишет значение, меняющееся каждую секунду, так что слой никогда не воспроизводится.
• Mtime файлов в архиве. Когда COPY . . пишет файлы в слой, tarball слоя записывает время модификации каждого файла. Свежий git checkout ставит mtime в сейчас, так что те же исходники, скопированные в два дня, дают два разных tarball-а с идентичным содержимым, но разными таймстампами — разный дайджест.
• Незапиненные базовые образы. FROM node:22 резолвится в тот дайджест, на который тег указывает сегодня; тег двигается на каждом минорном патче, так что пересборка спустя месяцы тянет другую базу и наследует её другие слои.

Лекарство от каждого прямое. Пиньте базу по дайджесту: FROM node:22@sha256:abc..., чтобы база не двигалась. Управляйте таймстампами через SOURCE_DATE_EPOCH — стандартизированную env-переменную с фиксированным Unix-временем (обычно дата автора коммита), которую инструменты сборки чтут вместо настенных часов. И заставьте BuildKit нормализовать mtime, которые он пишет.

# syntax=docker/dockerfile:1
FROM node:22@sha256:1a2b3c...      # запинено: база молча не сдвинется
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Подаём фиксированное время и просим BuildKit переписать таймстампы слоёв на него:
SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) \
  docker buildx build \
    --output type=image,name=app:v2.4.1,rewrite-timestamp=true .

rewrite-timestamp=true велит BuildKit выставить mtime каждого файла в производимых слоях в SOURCE_DATE_EPOCH, стирая разброс времени чекаута. С запиненной базой, запиненными часами и нормализованными mtime две сборки того же коммита на двух машинах дают те же дайджесты.

Детерминизм за пределами трёх больших рычагов

Пиньте базу, часы и mtime — и это покрывает большинство случаев, но несколько более тонких недетерминизмов стоят знания. Установки пакетов без пина версий (apt-get install curl без =version, pip install без lockfile) тянут что текуще, так что фиксируйте версии или используйте lockfile. Шаги сборки, выдающие вывод в порядке итерации ФС, могут варьироваться; инструменты всё чаще сортируют детерминированно, но кастомный скрипт может потребовать явной сортировки. Встроенные пути сборки (компилятор, записывающий /home/runner/...) различаются между машинами; многие тулчейны принимают remap префикса пути. А сетевой доступ во время сборки по природе невоспроизводим — тот же curl https://... может вернуть другие байты завтра, — поэтому герметичные сборки тянут лишь запиненные, контрольно-суммированные входы. Senior-позиция: трактуйте каждый вход сборки как нечто, что должно быть запинено или нормализовано, и считайте, что любой незапиненный вход в итоге сдвинется и сломает ваш дайджест, когда вы меньше всего хотите.