Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 6. Introduction to reproducible container builds


Red Hat Enterprise Linux (RHEL) now supports reproducible container builds using the Red Hat tools Podman and Buildah. This new feature reduces changes in images when users build them with the same inputs but at different times. Fewer changes between images can decrease the amount of data you need to pull from a registry when moving from one version of an image to a newer version of that image. Reproducible container builds are crucial for ensuring supply chain security, facilitating reliable software deployment, and facilitating effective debugging.

Previously, the escalating size of container images and increased customer apprehension regarding update payload sizes amplify the existing challenges and limitations associated with tarball creation. In systems like Konflux, each Git commit generates new tarballs, which necessitates a complete re-download of the entire image. Factors such as mtime changes mean that even when users install the same RPMs, storage requirements double, despite no alteration in the underlying data. This not only burdens registry storage but also forces clients to pull a new layer, even if no changes have occurred. This situation further exacerbates problems in environments like rhel-bootc and RHEL AI, which prioritize faster updates.

6.1. Benefits of reproducible container builds

Reproducible builds for RHEL containers reduce registry storage, create smaller update payloads, and enable faster downloads by ensuring the image layers remain consistent when the source code and build environment are unchanged. This process maximizes the efficiency of layer caching, preventing the redundant storage and transfer of identical data. The notable benefits of reproducible container builds are:

  • Reduced registry storage: When an image is updated, only changed layers are stored. Reproducible builds ensure identical images from the same source code by preventing non-deterministic factors (timestamps, file order, metadata) from causing changes, thus avoiding additional storage.
  • Efficient and smaller update payloads: For container minor updates, for example, security patches, only the changed layer needs to be downloaded, not the whole image. Reproducible builds also ensure that only affected layers change with source updates, unlike non-reproducible builds where small code changes can alter multiple layers.
  • Faster downloads: Container reproducible builds optimize both build systems and end users by enabling faster downloads through efficient caching, and reduced network traffic.

6.2. Impact of reproducible container builds on different environments

Reproducible container builds on RHEL ensure consistent, identical container images regardless of build time or location. The impact of reproducible container builds on diffrent environments are:

Konflux

  • Enhanced software supply chain integrity: Reproducible container builds enhance Konflux’s mission of delivering a secure and transparent software supply chain. Konflux uses reproducible builds to verify that a built container image derives exactly from its source code. Any third party can rebuild the container from the same inputs and verify that the output is bit-for-bit identical. Also, RHEL reproducible container builds protect against "in-transit" vulnerabilities, where an attacker can compromise a distribution mirror or inject malicious code into the build process. Konflux can prove that the released binary matches its source, mitigating attacks on its own build infrastructure.
  • Improved compliance and transparency: Konflux enforces SLSA security policies. It verifies the origin and provenance of reproducible RHEL images, simplifying compliance. Konflux uses Tekton Chains to create an immutable, signed attestation that documents the entire build process. RHEL’s reproducible container builds add a foundational layer of trust to this attestation by ensuring the base image is trustworthy and verifiably built.
  • Development and security workflows: Reproducible builds guarantee consistent container image digests across multiple runs, simplifying testing and debugging. Konflux leverages this to efficiently scan and update vulnerable packages in RHEL containers. Konflux uses verified attestations to automatically block non-compliant builds and enforce security policies without reducing flexibility.

Bootc

  • Verifiable supply chain and enhanced security: Reproducible RHEL container builds enhance rhel-bootc by creating a more secure, reliable, and transparent build process for bootable OS images. You can verify that a specific bootc image was built from its claimed source code, which makes it more difficult for attackers to inject malicious code into a container image by compromising a build pipeline.
  • Streamlined CI/CD and GitOps Workflows: You can use reproducibility to manage their entire OS configuration and application stack using Git-based workflows (GitOps). A change to the Containerfile, guarantees a consistent bootable image across all environments. Reproducible builds form a cornerstone of automated CI/CD pipelines.

RHEL AI

  • Reproducible container builds are critical for RHEL AI because they provide the foundational consistency, security, and efficiency AI model development and deployment need. RHEL AI delivers a bootable container image, which means it manages the operating system itself as a container artifact. Reproducibility ensures that this base AI environment is always consistent and trustworthy.

6.3. Achieving reproducibility in RHEL container tools

RHEL container tools provide a standardized, daemonless, and scriptable workflow using a suite of tools like Buildah, Podman and Skopeo to achieve reproducibility. This approach ensures that a container built once can run consistently anywhere, addressing potential issues with dependencies, environments, and versioning.

Buildah:

RHEL Buildah achieves reproducible container builds by providing granular control over the build process. It offers specific options to mitigate sources of non-determinism, such as unstable tags, filesystem metadata, and host-dependent data. The Buildah features for reproducible builds are:

  • Fixed timestamps: Timestamps cause major irreproducibility. By default, file creation and modification times reflect when someone adds a file to a container layer, which is never the same twice. Buildah allows you to zero out these timestamps or set them to a specific, fixed value.

    • -–rewrite-timestamp: This option timestamps the contents of layers to be no later than the --source-date-epoch. Also, controls the created timestamp of an image and the timestamps of files within its layers, primarily to achieve deterministic builds.
    • --source-date-epoch: This option is more flexible option than the older --timestamp option, allowing you to define a specific, reproducible timestamp for all files in the image layer. It affects creation and history dates in image metadata. You can set it by using CLI flag, environment variable, or as a build-arg. When the flag is set, declared ARGs are exposed in the environment for RUN instructions and get static hostname. Also, the container ID field is cleared in the committed image.

Podman:

The podman build command, while the user-facing interface, delegates the actual image creation to the Buildah library. This means that Podman achieves reproducible container builds by leveraging the same core features as Buildah, with a focus on controlling sources of non-determinism during the build process.

The Podman commands also accept the -–rewrite-timestamp and --source-date-epoch options. Additionally, the --no-cache option instructs Podman to disregard its local cache and perform a fresh build. Using this option helps verify that your container image can be reliably ruced from scratch.

Skopeo:

Skopeo achieves reproducible container builds by referencing immutable image digests instead of mutable tags. Skopeo primarily transports and manages images, while other tools like Buildah handle the actual reproducible image creation.

Using the --source-date-epoch and --rewrite-timestamp options can improve build reproducibility. However, complete reproducibility is not guaranteed. Content added from other images with the COPY instructions’s --from option, accessed through the RUN instruction’s --mount=from= option, or downloaded using the ADD instruction can change if you reference an image tag that later moves, or if the content at the specified URL changes.

6.4. Working with reproducible container builds

You can build a reproducible container image with -–source-date-epoch and -–rewrite-timestamp options, adding ARG SOURCE_DATE_EPOCH to the ContainerFile.

Procedure

  • To set these options when running your Buildah command. For example, to build an image from a Containerfile and force all timestamps to a specific point in time:

    Use a specific, immutable image.
    FROM registry.access.redhat.com/ubi9/ubi:9.4 AS builder
    
    # Set the SOURCE_DATE_EPOCH for deterministic timestamps
    ARG SOURCE_DATE_EPOCH
    ENV SOURCE_DATE_EPOCH=${SOURCE_DATE_EPOCH:-1}
    
    # Build the image using the build-arg and rewrite-timestamp options
    buildah bud --build-arg --source-date-epoch=${SOURCE_DATE_EPOCH} \
      --rewrite-timestamp \
      -f Containerfile \
      -t my-reproducible-image .
    Copy to Clipboard Toggle word wrap
  • Run the podman build command with a consistent timestamp to create the reproducible image:

    # Set a consistent timestamp using the last Git commit date
    export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
    Copy to Clipboard Toggle word wrap
  • Build the image with the specified timestamp:

    podman build --source-date-epoch=${SOURCE_DATE_EPOCH} --rewrite-timestamp -t my-reproducible-app .
    Copy to Clipboard Toggle word wrap

Verification

  • After building, run the reproducible command again. If the build is truly reproducible, the buildah inspect command should show the same image digest.

    buildah bud --build-arg --source-date-epoch=${SOURCE_DATE_EPOCH} \ --rewrite-timestamp \ -f Containerfile \ -t my-reproducible-image-2 .
    Copy to Clipboard Toggle word wrap
  • Compare the digests:

    buildah inspect --format '{{.Digest}}' my-reproducible-image
    buildah inspect --format '{{.Digest}}' my-reproducible-image-2
    Copy to Clipboard Toggle word wrap
Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat