はじめに
WebSphere Liberty 26.0.0.9で、UBI MicroをベースにしたLibertyコンテナイメージが追加されました。
UBI Microと聞くと、最初は少し分かりにくいかもしれません。
これは「コンテナ化そのもの」の名前ではありません。
Libertyをコンテナで動かすときに使う、Libertyコンテナイメージの選択肢の一つです。
これまでOSにWebSphere Application Server traditional、いわゆる tWAS 9.0.5 / 8.5.5 や Liberty をインストールして運用してきた環境では、OS、Java、WebSphere / Liberty、アプリケーション、運用ツール、調査用コマンドなどが、1つの環境に積み上がっていきます。
この運用は自然です。
障害時にOSへログインし、Linuxコマンドで確認し、必要に応じてパッケージを追加する。
長く使われてきたやり方です。
一方で、コンテナとしてLibertyを動かす場合は、少し考え方を変えるのが良いようです。
コンテナの中に、本当に必要なものだけを入れる。
アプリケーションが使わないOSパッケージや調査用ツールは、できるだけ入れない。
不要なものを除きたい、そのための選択肢の一つが、UBI MicroをベースにしたLibertyコンテナイメージです。
なぜ、そこまで小さくするのでしょうか。
理由は大きく2つあります。
1つ目は、使っていないものでも、入っていればCVE対応の対象になること。
2つ目は、入っていれば、侵入後に攻撃者が使える道具にもなり得ることです。
この記事では、Liberty UBI Microを単なる「軽量イメージ」としてではなく、WAS / Liberty を運用している人の視点で、CVE対応対象と侵入後の道具を減らす選択肢として見ていきます。
使っていないものでも、入っていればCVE対応対象になる
たとえば、あるLibertyアプリケーションが Java + Liberty + WAR だけで動いているとします。
そのアプリケーションが curl を使っていないなら、curl にCVEがあっても、アプリケーション機能に直接影響する可能性は低いかもしれません。
しかし、curl がコンテナイメージに入っていれば、脆弱性スキャンには出ます。
すると、次のような確認が必要になります。
- この
curlは使っているのか - アプリケーションから呼ばれているのか
- 起動スクリプトや運用手順で使っていないか
- 更新が必要なのか
- 削除できるのか
- 残す場合、どう扱うのか
- 再ビルドや再スキャンが必要か
ここで重要なのは、curl がアプリの機能テスト対象になる、という話ではありません。
アプリが使っていないなら、アプリ機能には直接関係しないかもしれません。
それでも、イメージに含まれている限り、脆弱性対応上の確認対象になります。
つまり、実行時には使っていないものが、CVE対応上の「大荷物」になることがあります。
この考え方は、curl に限りません。
wgetpingnet-toolsprocps- パッケージマネージャー
- 調査用ツール
- 追加ライブラリ
こうしたものがアプリケーション実行に不要であっても、イメージに含まれていればCVE対応の対象になり得ます。
使っていないものでも、入っていればCVE対応の対象になる。
だから、不要なら最初から入れない。
これが1つ目の気づきです。
入っていれば、侵入後の道具にもなり得る
もう1つの気づきは、侵入後の道具です。
仮に、アプリケーションの別の脆弱性を突かれて、コンテナ内で不正な処理が動いたとします。
そのとき、コンテナ内に curl や wget、シェル、パッケージマネージャーが入っていると、攻撃者にとって便利な道具になります。
アプリの脆弱性を突かれる
↓
コンテナ内で不正な処理が動く
↓
curl / wget / shell / package manager がある
↓
外部から道具を取得する
↓
内部偵察や横展開の準備へ進む
ここで問題にしているのは、curl のCVEがJavaアプリに直接影響するかどうかだけではありません。
curl という道具がそこにあることで、侵入後の次の一手を助ける可能性がある、という話です。
これは、運用者にとって便利な道具が、攻撃者にとっても便利な道具になり得る、ということです。
そのため、本番コンテナには、アプリケーション実行に不要な道具を入れない方がよい、という考え方になります。
入っていれば、侵入後の道具にもなり得る。
だから、不要なら最初から入れない。
これが2つ目の気づきです。
UBI Microを使う理由は、この2つにある
Liberty UBI Microを使う理由は、単にイメージサイズを小さくするためだけではありません。
このシリーズでは、UBI Microの価値を次の2本柱で考えます。
| 観点 | 何を減らすか | 期待できる効果 |
|---|---|---|
| CVE対応 | アプリが使っていないOSパッケージ | スキャン指摘、影響確認、更新判断、再スキャンの対象を減らしやすい |
| 侵入後の封じ込め | 攻撃者が使えるOSコマンドやパッケージマネージャー | 偵察、道具取得、横展開準備を進めにくくする |
つまり、UBI Microで小さくしたいのは、イメージサイズだけではありません。
- CVE対応対象
- 侵入後に使われる道具
- OS由来の確認範囲
- 本番コンテナに含まれる不要なもの
これらを小さくしたいのです。
なぜ今、コンテナ型を考えるのか
UBI Microの話に入る前に、そもそもなぜコンテナ型を考えるのかも整理しておきます。
OSにWebSphere/Libertyをインストールして使う構成では、1つのアプリケーションやシステムに対して、VMまたはサーバー単位で環境を用意することが多くあります。
この方式は分かりやすく、分離もしやすい一方で、次のような課題があります。
- アプリケーションごとにOSを持つため、OS管理対象が増えやすい
- OS、Java、Liberty、アプリ、運用ツールが同じ単位に積み上がりやすい
- サーバーやVMを増やすたびに、調達・構築・設定・パッチ適用が必要になる
- 小さなアプリでも、VM単位のリソースを確保しがちになる
- ハードウェア調達が遅れると、増設や更改の計画が遅れやすい
近年は、AI基盤やデータセンター需要の拡大により、サーバー部材や周辺インフラの調達制約が話題になることも増えています。
もちろん、すべての環境で同じように調達が難しいわけではありませんが、「必要になったらすぐサーバーを増やせる」とは限らない状況を意識する場面は増えています。
このような状況では、単にサーバーを追加するだけでなく、既存リソースをより細かく、効率よく使うことも重要になります。
VM型とコンテナ型の違い
VM型とコンテナ型を単純化すると、次のように整理できます。
| 観点 | VM型 | コンテナ型 |
|---|---|---|
| 実行単位 | OSを含むVM単位 | アプリケーションコンテナ単位 |
| OS管理 | VMごとにOSを持つ | ノードOSとコンテナイメージを分けて考える |
| リソース効率 | VM単位で余白が出やすい | アプリ単位で配置しやすい |
| 起動・再配置 | VM起動・構築に時間がかかりやすい | コンテナ単位で起動・再配置しやすい |
| 更新対象 | OS、ミドルウェア、アプリが混ざりやすい | ベースイメージとアプリ層を分けやすい |
| スケール | VM追加やサーバー増設に寄りやすい | 既存クラスタ上でアプリ単位に増減しやすい |
| 調達影響 | 新規サーバーやVM基盤増強の影響を受けやすい | 既存リソースの使い回し・高密度化を検討しやすい |
コンテナ型のメリットは、単に「新しい」ことではありません。
アプリケーション単位を軽く扱い、OS部分とアプリ部分を分け、既存リソース上でより細かく配置しやすくなることです。
もちろん、コンテナにすればサーバーが不要になるわけではありません。
Kubernetes/OpenShiftを動かすノードは必要ですし、クラスタ自体の設計・運用も必要です。
それでも、アプリケーションごとにVMを増やす方式と比べると、既存クラスタ上でアプリ単位に配置・更新・再起動しやすくなります。
ただし、コンテナ化だけでは不十分
コンテナ化すれば自動的に軽く、安全になるわけではありません。
コンテナイメージの中に、不要なOSパッケージや調査用ツール、パッケージマネージャーを入れすぎれば、次の問題が残ります。
- 使っていないOSパッケージがCVEスキャン対象になる
- アプリに関係ないCVEの確認が必要になる
- 侵入後に使える道具が残る
- イメージが大きくなる
- OS部分とアプリ部分の境界が曖昧になる
つまり、コンテナ化のメリットを活かすには、アプリケーション実行に不要なものをイメージに入れない ことが重要です。
ここでUBI Microが出てきます。
UBI Microは、コンテナ化のメリットをさらに活かすために、OS部分を小さく保つ選択肢です。
UBI Microとは何か
WebSphere Liberty 26.0.0.9では、Red Hat Universal Base Image Micro、つまり UBI Micro をベースにしたLibertyコンテナイメージが追加されました。
イメージ例は次のような形式です。
FROM icr.io/appcafe/websphere-liberty:kernel-java21-openj9-ubi-micro
UBI Microは、UBIファミリーの中でも特に小さい構成です。
特徴は、実行時に不要なパッケージやパッケージマネージャーを持たないことです。
OSにインストールして使う構成に慣れていると、これは不便に見えるかもしれません。
たとえば、障害時に次のようなコマンドを使いたくなることがあります。
ps -ef
netstat -an
curl http://localhost:9080/health
ping example.com
rpm -qa
UBI Microでは、こうしたコマンドが使える前提で考えません。
これは単なる制約ではありません。
本番コンテナに、アプリケーション実行に不要なものを入れない という考え方です。
中に入って調べる前提も変わる
UBI Microでは、本番コンテナに調査用のOSツールを入れない方向になります。
そのため、問題が起きたときに、コンテナの中へ入って ps、netstat、curl で調べる、という従来のやり方はやりづらくなります。
これは「デバッグできなくなる」という意味ではありません。
考え方を変えます。
コンテナの中に調査用の道具を増やすのではなく、外から見える経路を作っておく。
ログ、Health Check、Metrics、Traceなどを外に出し、問題が起きたときにコンテナへ入らなくても追えるようにします。
この具体策として、後半ではOpenTelemetryも扱います。
このシリーズで扱うこと
このシリーズでは、次の順番で見ていきます。
| 回 | テーマ | 見るポイント |
|---|---|---|
| 第2回 | OS部分とアプリ部分を分けて考える | CVEの出どころ、更新対象、確認範囲を整理する |
| 第3回 | OS依存を棚卸しする |
ping、curl、ps、netstat などが本当に必要か確認する |
| 第4回 | pingアプリでUBI Microを体感する | OSコマンド依存がUBI Microでどう表面化するかを見る |
| 第5回 | OpenTelemetryで外から見る | 中に入って調べる代わりに、外から見える経路を作る |
| 第6回 | ネット越しの攻撃とUBI Micro | CVE対応対象と侵入後の道具をどう減らせるか整理する |
第1回では、シリーズ全体の入口として、なぜUBI Microを考えるのかを整理しました。
実際にアプリケーションを選んだり、Dockerfileを作ったり、UBI MinimalとUBI Microを比較したりする作業は、第2回以降で順番に扱います。
まとめ
UBI Microを使う理由は、単にイメージサイズを小さくするためだけではありません。
アプリケーションが使っていないOSパッケージであっても、イメージに含まれていれば脆弱性スキャンの対象になります。
そのCVEが検出されると、使用有無や影響有無の確認が必要になります。
また、アプリケーションの別の脆弱性を突かれてコンテナ内で不正な処理が動いた場合、curl や wget、パッケージマネージャーは攻撃者にとって便利な道具になります。
つまり、
使っていないものでも、入っていればCVE対応の対象になる。
そして、入っていれば侵入後の道具にもなり得る。
だから、不要なら最初から入れない。
これがLiberty UBI Microを考えるうえでの中心メッセージです。
次回は、この考え方をさらに進めて、OS部分とアプリ部分を分けて考えることの意味を整理します。
参考情報
- IBM Community: Announcing UBI Micro Container Images for WebSphere Liberty in 26.0.0.9
- IBM Docs: Liberty container images
- IBM Support: Announcement: Upcoming Changes to the Container Images for IBM WebSphere Liberty and Open Liberty
- TrendForce: Extended Component Lead Times Weigh on General Server Growth; 2026 Server Shipments Forecast to Grow 13% YoY
- IDC: Servers Market Insights
- Reuters: HPE raises forecasts on AI demand, shares fall on supply concerns