UBI redistribution, read against the entitlement.

Red Hat UBI licensing rules describe the terms under which the Universal Base Image and its four variants (ubi, ubi minimal, ubi micro, ubi init) may be built upon, distributed, and run by parties who do not hold a paid RHEL subscription. The image is published in the Red Hat container catalog under the Red Hat Universal Base Image End User License Agreement. The EULA permits redistribution of the image and of derivative images, permits running the image in production, and permits commercial use, all without a RHEL subscription on the host that runs the container. The boundary the EULA draws sits elsewhere, on the packages that may be installed into the image and on the support model that applies to the container at runtime.1

The four variants exist to give the container author a footprint choice. The full ubi image carries the standard package set; ubi minimal carries a reduced set adequate for most application containers; ubi micro carries only the libraries needed to execute a single statically linked binary; ubi init carries a systemd unit suitable for traditional service style containers. The licensing reading is identical across the four; the package set differs and the audit reading on the derived image set differs in proportion. The image footprint choice interacts with the broader treatment of image builder posture in the RHEL image builder and image mode licensing note.

The relationship to RHEL is the part of the licensing reading that is frequently misstated. UBI is a derivative of the RHEL package set; the binaries that ship in ubi are RHEL binaries; the package repositories the image points at are the UBI repositories, which are a curated subset of the RHEL repositories. A buyer who installs a package present in ubi using the dnf or yum tooling against the UBI repositories has stayed inside the EULA. A buyer who installs a package not present in the UBI repositories, by pointing the package manager at a private mirror of the full RHEL repositories, has reentered the RHEL entitlement scope on the host that built the image. The cross reading on the host side sits in the RHEL practice hub.

Three boundaries the UBI EULA draws recur on every container audit reading. Each is structural; each remediates inside an internal review or a renewal cycle.

The first boundary is the package set added to the image. Packages in the UBI repositories may be installed without a RHEL entitlement on the build host or the runtime host; packages outside the UBI repositories may not. The procurement register that lists the FROM lines of the container registry catches only the first level of the reading; the dnf install lines inside the Dockerfile and the package layers actually present in the built image are the artifacts the audit walks. The sibling treatment of the container tooling that performs the build sits in the RHEL podman, buildah, and skopeo licensing note. A FROM line that reads ubi is the start of the reading, not the end.2

The second boundary is the support model at runtime. The UBI EULA does not include Red Hat support; the container that runs in production under UBI has no claim on Red Hat for an errata patch, a security backport, or a technical issue against the binaries in the image. A buyer who treats the production estate of UBI containers as supported by Red Hat is reading the EULA against a support model that does not apply. The remediation, for a buyer who wants supported binaries in production, is the Red Hat OpenShift entitlement or the RHEL entitlement on the runtime host, depending on the runtime context. The cross cluster bridge sits in the Red Hat Quay registry licensing note , which carries the equivalent reading on the registry side.

The third boundary is the build host. The host that runs podman build or buildah against a UBI base image executes RHEL binaries during the build; that host requires a RHEL entitlement if the host itself is RHEL. The EULA permits the build to occur on a host that is not RHEL (a developer laptop, a Fedora workstation, a third party Linux host) without a RHEL entitlement on that host. The pattern is frequently misread inside an estate that runs the container build pipeline on a RHEL based CI fleet; the CI fleet requires entitlement under the standard RHEL terms, regardless of the UBI status of the resulting image. The pattern overlaps with the treatment of the developer subscription boundary in the RHEL developer program versus enterprise subscription note.

The audit reading on a UBI estate walks four artifacts. The image catalog with FROM line tags resolved, the Dockerfile or Containerfile source for each derived image, the package layer manifest extracted from each built image, and the build host inventory for the CI pipeline that produced the registry. The reading is internally consistent when the package layers present in every image trace back to either the UBI repositories or to a non Red Hat source, with no package present that originates in the full RHEL repositories absent a corresponding RHEL entitlement on the build host.3

The most common audit reading misstep on a UBI estate is the unaudited Dockerfile. A Dockerfile that points a private package mirror back at the full RHEL repositories, or that copies a package binary into the image from a build artifact produced elsewhere, can pull a RHEL package into the derived image without ever issuing a dnf install against a Red Hat hosted repository. The reading on the image is identical to the case where the package was installed from cdn.redhat.com; the entitlement scope reasserts. The remediation is the source level review of the Dockerfile set at the registry, performed inside a quarterly internal review. The broader treatment of evidence collection sits in the deployment evidence in audit defense note.

The second misstep is the build host that is RHEL but uncounted. A CI fleet that runs RHEL on the container build hosts and reports those hosts to subscription manager carries an entitlement requirement on the host count regardless of what the resulting images contain. The pattern is most frequently observed in enterprises that built their CI fleet on RHEL during the CentOS migration and continue to read the fleet as a pure container build estate rather than a RHEL fleet. The cross reading sits in the counting RHEL systems accurately note.

The renewal economics on a UBI estate sit on three structural decisions made earlier in the pipeline.

The first decision is whether the container build is held inside the UBI repositories or allowed to reach into the full RHEL repositories. A pipeline held to UBI removes the entitlement requirement on the runtime estate of containers entirely; a pipeline that reaches the full repositories carries the entitlement requirement at every runtime host that runs those containers. The procurement register that walks the registry at the renewal cycle, against the package manifest of every image, can quantify the cost of pipelines that reach outside UBI and inform the next cycle's pipeline policy. The discipline overlaps with the broader assessment framework in subscription assessment.

The second decision is the OpenShift runtime entitlement. A buyer who runs UBI based containers on OpenShift holds the OpenShift entitlement at the cluster level; the UBI EULA reading and the OpenShift entitlement are separate domains. The OpenShift entitlement does not extend to RHEL based containers outside the cluster, and the UBI EULA does not require an OpenShift entitlement on its own terms. The two entitlements coexist; neither substitutes for the other. The sibling treatment of the runtime side sits in the RHEL image builder and image mode licensing note.4

The third decision is the support posture for the UBI runtime. The UBI EULA does not include Red Hat support; a buyer who needs support for the binaries in a UBI container at runtime acquires that support through a RHEL or OpenShift entitlement on the runtime host or cluster. The procurement register that prices the runtime support requirement against the runtime fleet, separate from the build pipeline cost, produces the renewal reading the negotiation depends on. The broader treatment of renewal cycle discipline sits in renewal negotiation.

The renewal posture on a UBI estate has three habits.

The first habit is the registry walk at the cycle. Every image in the production registry is resolved to its package layer manifest; every package is checked against the UBI repository list; every package outside the UBI list is traced to a Dockerfile and a source. The walk is performed before any rationalisation discussion with Red Hat; the buyer who walks into the discussion with the registry walk in hand reads the conversation differently. The pattern sits inside the broader frame of recoverable over entitlement cost.

The second habit is the build host segmentation. The CI fleet is reported separately from the runtime fleet in the procurement register; the entitlement for the build hosts is sized to the actual build workload, not to the registry size; the runtime entitlement is sized to the workload that requires Red Hat support at runtime, not to the registry catalog. The discipline parallels the treatment in aligning subscription to deployment.

The third habit is the periodic Dockerfile review. The Dockerfile set in the registry is reviewed inside a quarterly internal cadence; new sources of packages are noted; pipelines that have reached outside UBI are flagged for either remediation or for entitlement assignment. The discipline is small; the audit benefit on the next cycle is structural. For an engagement against the desk, see the contact form.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.