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

Implementing the vendor-image pipeline

End-to-end pipeline for sealing a vendor image and deploying the sealed copy from your private registry.

The vendor-image pipeline pulls a vendor image, seals it, pushes the sealed result into your private registry, and your deployments pull from there. Two equivalent ways to drive the seal step:

Approach 1: seal image fix

The CLI's seal image fix command does the whole pull-seal-push in one invocation. The simpler path.

export SEAL_TOKEN=<token>
export SEAL_PROJECT=my-vendor-image
export SEAL_USE_SEALED_NAMES=1   # rename sealed packages so external scanners do not flag them

seal image fix \
  confluentinc/cp-kafka:latest \
  --platform linux/amd64 \
  --tag your-org-registry/cp-kafka:2026-06-01

The --tag flag is what makes this different from Seal My Container's in-place overwrite pattern: you cannot push back to the vendor's registry, and even if you could, redistributing would violate the vendor's licensing. The sealed image lands at a reference inside your own private registry instead.

Running against :latest (or any other moving vendor tag) is fine — the source is moving, but the destination tag you write is pinned. Schedule the pipeline to re-run on whatever cadence makes sense for your team; each run picks up the vendor's current latest and produces a fresh sealed copy under a new destination tag.

Approach 2: a Dockerfile with explicit seal steps

When you want explicit control over the surrounding build — to add --silence flags for known false positives, to capture a structured summary at a specific path, to seal application artifacts the vendor packed in non-default locations, or to extend the sealing to Python wheels — write the Dockerfile yourself.

The OS-layer step uses seal fix --os. Application-artifact steps use seal fix --fs <ecosystem> <path>: --fs java <path> for JARs and --fs python <path> for wheels. A typical vendor image with both OS packages and JARs (a Kafka-style image, for example):

# syntax=docker/dockerfile:1
FROM --platform=linux/amd64 confluentinc/cp-kafka:latest

ADD --chmod=755 https://github.com/seal-community/cli/releases/download/latest/seal-linux-amd64-latest /seal
USER root
ARG SEAL_PROJECT=my-vendor-image
ENV SEAL_USE_SEALED_NAMES=1

RUN --mount=type=secret,id=SEAL_TOKEN,env=SEAL_TOKEN \
    /seal fix --os --mode=all --clean

RUN --mount=type=secret,id=SEAL_TOKEN,env=SEAL_TOKEN \
    /seal fix --fs java / --mode=all --clean --remove-cli

# If the vendor's image dropped privileges, restore them at the end.
# USER appuser

seal fix --fs java / recursively scans the whole filesystem and seals any vulnerable JARs it finds. Narrow the path (/usr/share/java, /opt/kafka/libs, and so on) when you know where the vendor packed them; the seal step is faster and the build log is easier to read.

For an image carrying Python wheels, add a step pointing at the wheel directory:

Only one RUN step in the same Dockerfile should carry --remove-cli; apply it to the last seal step so /seal is removed exactly once, at the end.

Then a regular docker build and docker push:

The OS-and-JARs result is byte-for-byte equivalent to what seal image fix produces against the same vendor tag; seal image fix runs the same two steps internally.

Tag conventions

The destination tag goes into your private registry. Two common conventions:

  • Mirror the vendor's repository path under your namespace. confluentinc/cp-kafka:7.9.0 → your-org-registry/cp-kafka:7.9.0. The image's name stays recognizable; the registry changes.

  • Tag by seal date when re-sealing against a moving vendor tag. your-org-registry/cp-kafka:2026-06-01 for the seal run on 2026-06-01. Useful when the source is :latest and you want a date-stamped record of what each run produced.

Either way, every deployment manifest in your environment references the sealed tag in your private registry, never the vendor's original.

Renaming sealed packages inside the image

When the resulting sealed image will be scanned by an external scanner that does not consume Seal's vulnerability feed, enable renaming so the scanner does not flag the sealed packages. Set SEAL_USE_SEALED_NAMES=1 in the environment (Approach 1) or as ENV / ARG in the Dockerfile (Approach 2). The mechanics are the same as in Seal My Container's renaming page. Renaming is the recommended default.

When to seal

Two patterns work:

  • On a schedule, against a moving vendor tag. A nightly or weekly job runs the pipeline against confluentinc/cp-kafka:latest (or whatever moving tag the vendor publishes). Each run pulls the vendor's current release and the latest sealed-package set Seal has published, producing a fresh sealed image under a date-stamped destination tag. Deployments roll forward as the new tag rolls into the manifests.

  • Pinned, on vendor-release events. When the vendor publishes a specific version you want to adopt, run the pipeline against the pinned vendor tag (confluentinc/cp-kafka:7.10.0) and produce a sealed counterpart (your-org-registry/cp-kafka:7.10.0). Update the deployment manifests to reference the new sealed tag. This is the right pattern when you need explicit per-version traceability — for example, in regulated environments where each production deploy must reference a specific vendor release.

The scheduled pattern is the lower-friction default; the pinned pattern fits stricter change-management environments.

Deployments

Once the sealed image is in your private registry, deployments reference the sealed tag. The change is a one-line edit in the deployment manifest, Helm chart, or Compose file:

For Kubernetes deployments, the standard imagePullSecrets for the private registry covers the pull. No additional manifest changes are needed beyond repointing the image reference.

What is not redistributable

The sealed image contains the vendor's application code. The vendor's license likely forbids redistribution. The sealed image is for your internal use only. Do not push it to a public registry; do not share it across organizational boundaries. Internal use across teams inside the same legal entity is typically fine; consult the vendor's licensing terms if you are unsure.

Related

PreviousSeal Vendor AppsNextUsing the Seal Platform

Last updated