Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Pulling a sealed base image

Reference a Seal base image from a Dockerfile, or pull it directly.

Once your image-pull layer is authenticated against Seal's registry, pulling a sealed base image is identical to pulling any other OCI image: a docker pull, a podman pull, or a FROM reference in your Dockerfile. This page covers the reference format and the canonical patterns.

The reference format

Every sealed image is identified by three parts, plus the registry hostname:

<seal-registry>/<image>:<upstream-version>-<build-timestamp>-sp<N>

  • <image> is the upstream image's name (python, node, openjdk, elasticsearch, and so on).

  • <upstream-version> is the upstream tag this sealed iteration was built from (3.12.9-slim-bullseye, 21-jdk-alpine, 8.13.4, and so on).

  • <build-timestamp> is the moment the upstream tag was pulled by Seal, in compact ISO 8601: YYYYMMDDTHHMMSSZ (for example, 20250408T180700Z). This pins the sealed image to a specific point-in-time of the upstream tag.

  • sp<N> is the sealed iteration: sp1 is the first sealed iteration of that build-timestamped upstream snapshot, sp2 is the next, and so on. Each spN is cumulative — every fix from earlier iterations plus the new ones.

A concrete example, for a sealed Python 3.12 slim Bullseye image:

<seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp2

This is the second sealed iteration of the upstream python:3.12.9-slim-bullseye image as pulled by Seal on 2025-04-08 18:07:00 UTC.

Your Seal account team provides the exact reference for each sealed image enabled for your tenant. Use that reference verbatim; do not construct it from parts.

Using a sealed image in a Dockerfile

Change the FROM line. Nothing else changes:

# Before
# FROM python:3.12.9-slim-bullseye

# After
FROM <seal-registry>/python:3.12.9-slim-bullseye-20250408T180700Z-sp2

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "main.py"]

The rest of the Dockerfile is unchanged. The sealed base image preserves the file layout, default user, entrypoint, and shell of the upstream image; anything that worked against the upstream still works against the sealed counterpart.

Pulling directly

For inspection, smoke testing, or pre-fetching for an offline build, pull the image directly with docker or podman:

Once cached locally, the image is available for docker run, docker inspect, or any other docker subcommand. The output of docker inspect shows the same configuration the upstream image would, plus the labels Seal adds during sealing.

Pinning strategy

Because the reference includes both the build-timestamp and the sealed iteration, every FROM line you check in points at one specific image. There is no rolling latest tag for a Seal Base Image: a tag like python:3.12.9-slim-bullseye-20250408T180700Z-sp2 resolves to exactly one image, today and tomorrow.

To pick up a newer sealed iteration when one ships (sp3, sp4, and so on), update the FROM line. The mechanics are documented in Updating to a new base image release.

This is intentional. Container builds that depend on :latest are notoriously hard to reproduce; Seal Base Image references give you a sealed equivalent without giving up the reproducibility of a pinned tag.

Multi-arch images

Each sealed image is published as a manifest list spanning the architectures the upstream image supports (typically linux/amd64 and linux/arm64). A regular docker pull resolves to the right architecture for the host automatically; specify --platform=linux/arm64 (or --platform=linux/amd64) if you need to pull an architecture other than the host's, the same way you would for any upstream multi-arch image.

If the upstream image is single-architecture, the Seal counterpart is also single-architecture. Your Seal account team confirms which architectures are available for each sealed image.

Verifying signatures

Every sealed image is signed with cosign against a Seal-owned key. The trust setup and the verification commands are documented under Cryptographic signing and hash verification; the short version is:

A successful verify confirms the image was published by Seal and has not been tampered with in transit. For policy-driven environments (Kyverno, Sigstore Policy Controller, Gatekeeper), use the same key to enforce signature requirements at pod-launch time.

Attestations

Each sealed image ships with a VEX attestation listing the vulnerabilities that have been remediated and an SBOM listing the packages inside. Both are attached to the image as cosign attestations and can be downloaded from the registry alongside the image. The full attestation model is documented under Attestations.

Related

PreviousAuthenticating with Seal's image registryNextMirroring to your internal registry

Last updated