RHEL UBIコンテナイメージ本番採用｜ライセンス制約と商用RHEL差分の事前確認フロー

Red Hat Universal Base Image（UBI）は、RHELの実績をコンテナベースイメージとして無償で利用・再配布できる仕組みとして広く普及しています。しかし「無償で使える」という一文だけを根拠に本番採用を進めると、パッケージ可用性の不足・サポートスコープの誤解・再配布ポリシー違反といった問題が後から発覚するケースがあります。本記事では、採用判断前に押さえるべきライセンス構造の整理から、商用RHELとの実務的な差分確認、本番稼働後の切り戻し観点まで、一連のフローとして解説します。

UBIコンテナイメージとは何か、なぜ本番採用が増えているか

UBIは2019年にRed Hatが公開した、RHELをベースとする公式コンテナイメージ群です。従来のRHELコンテナイメージはサブスクリプション契約が前提でしたが、UBIはRed Hat Universal Base Image End User License Agreement（UBI EULA）のもとで再配布が許可されており、DockerHubやRed Hat Ecosystemカタログから誰でも取得できます。

現在公開されているUBIのバリアントは主に4種類です。フル機能を持つubi9（またはubi8）、パッケージマネージャを絞り込んだubi9-minimal、dnf自体を取り除いた超軽量のubi9-micro、そしてsystemdを内包してサービス管理を可能にしたubi9-initがあります。用途に応じて選択できる点が運用現場に好まれる理由のひとつです。

本番採用が増えている背景には、エンタープライズ向けのセキュリティパッチ提供サイクルへの信頼感と、OpenShift・ACM（Advanced Cluster Management）などRed Hatのプラットフォーム製品との相性の良さがあります。ただし「無償で利用できる」という事実と「商用RHELと同等に使える」という期待の間には、無視できないギャップが存在します。

ライセンス構造の要点──UBI EULAと商用サブスクリプションの境界

UBI EULAが許可しているのは、UBIイメージ自体およびUBIリポジトリ由来のパッケージの利用と再配布です。一方、商用RHELサブスクリプションに紐づいたRHELリポジトリ（例：rhel-9-for-x86_64-baseos-rpms や rhel-9-for-x86_64-appstream-rpms）から取得したパッケージは、再配布が制限されます。

重要な実務的帰結として、サブスクリプション登録済みのRHELホスト上でコンテナをビルドする場合、ホストのサブスクリプション情報がコンテナビルド環境に引き継がれ、RHEL全リポジトリが参照できる状態になります。この環境でビルドしたイメージにはサブスクリプション限定パッケージが含まれる可能性があり、そのイメージをそのまま社外や非RHELホストに配布すると、ライセンス上の問題が生じます。

UBI EULAの範囲内で再配布可能かを判断する実践的な基準は「そのパッケージはUBIリポジトリに存在するか」です。UBIリポジトリの一覧はRed Hat Container Catalogで確認でき、ubi9/ubiイメージ内からdnf repolistを実行したときに表示されるリポジトリIDが、UBI EULAの範囲を示しています。

商用RHELとUBIの実務的な差分チェックリスト

本番採用前に確認が必要な差分は、大きく三つの領域に分類できます。

• パッケージ可用性： UBIリポジトリは商用RHELリポジトリの完全なサブセットではありません。多くのミドルウェアや開発ツールはUBIリポジトリに存在せず、インストールしようとするとパッケージが見つからないエラーになります。アプリケーションが依存するRPMをリスト化し、それぞれがUBIリポジトリ内に存在するかを事前に照合する作業が必要です。
• サポートスコープ： UBI自体へのセキュリティアドバイザリはRed Hatが提供しますが、個別のサポートリクエスト（テクニカルサポート）を受けられるのは、サブスクリプション契約済みの商用RHELホスト上で動作している場合に限られます。非RHELホスト（Debian系ディストリ上のDockerなど）で動作させる場合、コンテナ内のOS部分に対する個別サポートは受けられません。
• Kernelおよびセキュリティ認定： コンテナはホストのKernelを共有するため、UBIイメージ自体にKernelは含まれません。FIPS 140-2/140-3準拠やCommon Criteria認定といったコンプライアンス要件がある場合、ホストOS側の認定状況と組み合わせた確認が必要です。UBIコンテナ単独での認定主張はできません。

本番採用前の事前確認フロー

上記の差分を踏まえ、採用判断から本番投入までの確認作業を以下の順序で進めることが現場では有効です。

ステップ1：必要パッケージのリポジトリ可用性確認

まず、サブスクリプションを持たないクリーンなUBIコンテナを起動し、その中でアプリケーションの依存パッケージをdnf install --assumenoオプションで試行します。サブスクリプション情報を持ち込まない状態で確認することで、UBIリポジトリのみで解決できるかどうかを正確に判定できます。この検証はRHELホスト上ではなく、非RHELの環境（CIランナーやDockerが動くLinuxホスト）で実施するのが確実です。

UBIリポジトリで解決できないパッケージがある場合、代替手段としては「サードパーティのRPMリポジトリを追加する」「ソースからビルドする」「必要な機能を提供する別パッケージをUBIリポジトリ内で探す」の3択になります。サードパーティリポジトリを追加する場合は、そのリポジトリ独自のライセンス条件も別途確認が必要です。

ステップ2：ホスト環境とサポートスコープの確認

本番稼働先がOpenShiftまたはサブスクリプション済みRHELであれば、コンテナ内のUBIコンポーネントに対するサポートも契約の範囲内に含まれます。一方、AWS ECS・GKE・Azure AKS等のマネージドKubernetesサービス上にそのまま乗せる場合は、コンテナ内のOS部分はRed Hatのサポート対象外となります。この違いはインシデント発生時の問い合わせ経路に直結するため、SLA設計段階で明確にしておく必要があります。

ステップ3：再配布・コンプライアンス要件の確認

イメージを社外に配布する場合（SaaS製品のベースイメージとして同梱する場合など）は、ビルド環境にサブスクリプション情報が混入していないかを確認します。具体的には、ビルド後のイメージ内でdnf repolistを実行し、表示されるリポジトリがUBIリポジトリのみであることを確かめます。subscription-manager関連のファイルがイメージに残っていないかも確認ポイントです。

コンプライアンス観点では、イメージに含まれるパッケージのCVEステータスとライセンスをSBOM（Software Bill of Materials）として記録しておくことが、2026年時点では多くの業界で推奨あるいは義務化されつつあります。Red Hat Container Catalogが提供するイメージスキャン結果やセキュリティアドバイザリページを活用して、SBOMの一部として取り込む運用が広まっています。

検証と切り戻しの指針

本番投入前のステージング検証では、以下の観点を押さえることが重要です。まず、アプリケーションが期待どおりに動作するかに加え、不要なパッケージがイメージに含まれていないかを確認します。UBIのフルイメージはdnfを含むため、最終的にdnfが不要な場合はubi-microやdistrolessへの置き換えを検討します。イメージサイズの削減はそのまま攻撃対象領域の縮小にもつながります。

切り戻しの観点では、UBIのタグ運用に注意が必要です。ubi9:latestタグは更新されるため、本番環境ではubi9:9.4-1194のようにマイナーバージョンまで固定したタグを使用します。Red HatはUBIの旧バージョンを一定期間保持しており、問題が発生した場合は直前のダイジェスト（sha256:…）を指定してロールバックできます。Podmanまたはdocker環境でimage inspectによりダイジェストを事前に記録しておくことを、リリース手順に組み込んでおくと安全です。

また、ベースイメージの更新（セキュリティパッチ適用）を定期的にどう取り込むかも、採用前に決めておく必要があります。UBIのセキュリティアドバイザリはRed Hatのエラータページで公開されており、新しいイメージが公開されたタイミングで自動リビルドを走らせるCIパイプラインを整備することが、現場では標準的な対策となっています。

2026年現行環境での注意点

2026年10月時点での主な環境変化として、いくつか把握しておくべき点があります。

まず、UBI9（RHEL 9系）が現行の主軸です。UBI8はRHEL 8のEOL（2029年5月）まで継続提供されますが、新規プロジェクトはUBI9での構築が推奨されます。UBI9はglibc 2.34以降を前提とするため、古いバイナリを持ち込む場合は互換性の確認が必要です。

次に、コンテナランタイムの変化があります。RHEL 8以降、Red HatはDockerではなくPodmanを標準として位置づけています。OpenShift 4系でもCRI-Oがランタイムです。Podman特有のrootlessモードやpodman buildの挙動はDockerと概ね互換性がありますが、ビルドキャッシュの扱いやマルチプラットフォームビルドの設定方法に差異があります。既存のDockerfileをそのまま流用できる場合がほとんどですが、--privilegedフラグへの依存や特定のVOLUME命令の挙動は事前確認が必要です。

また、CentOS Streamの位置づけを混同しないよう注意が必要です。CentOS Streamは商用RHELの「アップストリーム」であり、UBIとは異なります。UBIはRHELの安定リリースを元にしており、CentOS StreamベースのイメージはUBIとは別物です。2025年以降、Rocky LinuxやAlmaLinuxのコンテナイメージを採用している現場もありますが、それらはUBI EULAではなく各プロジェクトのライセンス条件が適用されます。

最後に、SBOMとサプライチェーンセキュリティへの対応です。米国の行政命令（EO 14028）およびそれに追随する各国の規制動向を受けて、コンテナイメージのSBOM提出を要件とする調達案件が増えています。Red Hat Container Catalogで公開されているUBIのSBOMデータ（CycloneDX/SPDX形式）を活用することで、提出義務への対応コストを大幅に削減できます。自社でビルドしたレイヤ部分については、syftやtrivyなどのOSSツールで補完するパターンが現場では広く使われています。