はじめに
このシリーズでは、これまで次のような内容を見てきました。
- UBI Microとは何か
- OSにインストールして使ってきたWebSphere/Liberty環境から見ると何が変わるのか
-
pingやcurlなど、OSコマンドに依存した作りがどう見えてくるのか - OpenTelemetryで、コンテナの中に入らずアプリケーションの状態を見る考え方
今回は、少し踏み込んで セキュリティ の観点からUBI Microを見ます。
このシリーズでは、UBI Microを使う理由を次の2本柱で見てきました。
- アプリが使っていないOSパッケージを減らし、CVE対応対象を小さくする
- 侵入後に攻撃者が使えるOS上の道具を減らす
さらに、UBI Microで本番コンテナ内の道具を減らすなら、ログ、Health Check、Metrics、Traceのように、外から見える経路を作る必要があります。
ただし、最初に強調しておきたいことがあります。
UBI Microは、ネット越しの攻撃入口をすべて塞ぐ魔法のイメージではありません。
Webアプリケーションの脆弱性、APIの認証認可不備、管理エンドポイントの公開、依存ライブラリの脆弱性、設定ミスなどは、UBI Microだけでは防げません。
では、UBI Microには何の意味があるのでしょうか。
この記事では、UBI Microを 「侵入後の攻撃チェーンを短くするための選択肢」 として整理します。
この記事で扱うこと
この記事は、次のような方を想定しています。
- tWAS 9.0.5 / 8.5.5 や Liberty をOSにインストールして運用してきた方
- これからLibertyコンテナやOpenShift/Kubernetesを検討する方
- セキュリティ専門職ではないが、CVE対応や脆弱性スキャンを扱う機会がある方
- UBI Microを「小さいイメージ」以上の意味で理解したい方
この記事では、攻撃手法を詳しく説明することは目的にしません。
目的は、UBI Microが防げること、防げないこと、そして他の対策とどう組み合わせるか を整理することです。
UBI Microは「入口対策」ではなく「その後を進めにくくする対策」
ネット越しの攻撃では、攻撃者が最初からコンテナの中にいるわけではありません。
多くの場合、入口は次のようなものです。
- Webアプリケーションの脆弱性
- APIの認証認可不備
- 管理画面や管理APIの公開
- 依存ライブラリの脆弱性
- 設定ミス
- 不要なエンドポイントの公開
ここは、UBI Microだけで塞ぐ領域ではありません。
アプリケーション修正、依存ライブラリ更新、認証認可、ネットワーク制御、管理エンドポイントの非公開化などで対応する領域です。
一方で、攻撃が成立した後には、攻撃者は次の行動を取ろうとします。
- コンテナ内を調べる
- 使えるコマンドを探す
- 足りない道具を持ち込む
- 環境変数や設定ファイルを確認する
- 外部通信や横展開を試みる
- 居座る方法を探す
UBI Microが効いてくるのは、この 侵入後の段階 です。
フル版に近いイメージでは、OSツールやパッケージマネージャーが残っている場合があります。
それは運用者にとって便利ですが、万が一侵害された場合には、攻撃者にとっても便利な道具になります。
UBI Microでは、実行時に不要なOSコンポーネントを極力減らします。
パッケージマネージャーも持ちません。
そのため、攻撃が成立した後の「調べる」「道具を入れる」「広げる準備をする」という段階を進めにくくできます。
ネット越しの攻撃ベクトルとUBI Microの関係
UBI Microの効果を考える前に、まずネット越しにどこを狙われるのかを整理します。
| 攻撃ベクトル | 例 | UBI Microで直接防げるか | 主な対策 |
|---|---|---|---|
| Webアプリの脆弱性 | 認可漏れ、入力検証不備、Injection、SSRF、RCE | 防げない | アプリ修正、依存更新、セキュリティテスト、WAF |
| APIの公開面 | 想定外のAPI公開、認証不足、過剰な権限 | 防げない | 認証認可、API Gateway、アクセス制御 |
| 管理画面・管理API | Admin Console、管理REST、JMX、監視エンドポイント | 防げない | 外部公開しない、認証強化、ネットワーク制限 |
| 依存ライブラリの脆弱性 | Log4Shell型のRCE、古いOSSライブラリ | 防げない | SBOM、依存更新、脆弱性スキャン |
| コンテナOSの余分なパッケージ | 不要なOSツール、古いパッケージ、余分なライブラリ | 減らせる | UBI Micro、最小イメージ、スキャン |
| 侵害後の道具利用 |
curl、sh、ps、netstat、microdnf など |
減らせる | UBI Micro、readOnlyRootFilesystem、最小権限 |
| 外部通信の悪用 | 道具の取得、不要な宛先への通信、横展開準備 | 直接は防げない | NetworkPolicy、egress制御、プロキシ制御 |
| 書き込み可能領域の悪用 |
/tmp への配置、一時ファイル、改ざん |
直接は防げない | readOnlyRootFilesystem、volume制御、Pod再作成 |
| Secretの悪用 | 環境変数、設定ファイル、ServiceAccount token | 防げない | Secret管理、RBAC、権限最小化 |
この表で見たいのは、UBI Microが万能ではないという点です。
Webアプリケーションの脆弱性や依存ライブラリの脆弱性は、UBI Microでは直接直りません。
管理エンドポイントをインターネットに公開してしまっている場合も、UBI Microでは解決しません。
一方で、コンテナOSの余分なパッケージや、侵害後に利用されやすいOS上の道具は、UBI Microで減らしやすい領域です。
攻撃が成立した後の段階で見る
もう少し攻撃の流れとして見てみます。
第0段階：ネット越しに攻撃される
↓
第1段階：脆弱性を突かれ、アプリ内で任意コード/任意コマンド実行に近い状態になる
↓
第2段階：コンテナ内を調べる
↓
第3段階：追加の道具を持ち込む
↓
第4段階：横展開・情報収集・外部送信を試みる
↓
第5段階：持続化・再侵入・長期滞在を試みる
この流れで見ると、UBI Microが特に効くのは主に 第2段階と第3段階 です。
| 段階 | 攻撃者がやりたいこと | フル版/通常イメージ | UBI Microでどう変わるか |
|---|---|---|---|
| 0. ネット越しの入口 | Webアプリ、API、管理画面、依存ライブラリを狙う | 入口は存在し得る | ここは防げない |
| 1. 攻撃成立 | RCE、任意コマンド実行、任意ファイル操作に近い状態になる | アプリの穴次第 | ここも基本は防げない |
| 2. 偵察 |
whoami、ps、netstat、ip、ls、env などで中を見る |
道具が残っている可能性が高い | 使える道具が減る |
| 3. 道具の追加 |
curl、wget、dnf、yum、microdnf などで取得・追加 |
追加しやすい | パッケージマネージャーがなく、追加導入しにくい |
| 4. 横展開準備 | 認証情報探索、外部接続、内部ネットワーク確認 | OSツールを使いやすい | 標準装備だけではやりにくい |
| 5. 持続化 | ファイル配置、プロセス常駐、再侵入経路作成 | 書ける場所があれば可能 | UBI Micro単体では不十分。readOnlyRootFilesystem やPod再作成が必要 |
ここでのポイントは、UBI Microを過大評価しないことです。
UBI Microは、第0段階と第1段階を直接止める対策ではありません。
入口対策は、アプリケーション修正、依存更新、認証認可、管理エンドポイントの非公開化、ネットワーク制御で行います。
一方で、攻撃が成立した後の 第2段階以降 では、イメージの作り方が効いてきます。
フル版に近いイメージでは、OSツールやパッケージマネージャーが残っていることがあります。
その場合、攻撃者にとっては侵入後の偵察や追加ツール導入がしやすくなります。
UBI Microでは、パッケージマネージャーとその依存関係を持たず、実行時に不要なOSツールを極力減らします。
そのため、攻撃が成立した後でも、次の段階である 「内部偵察」「道具の追加」「横展開準備」 を進めにくくできます。
つまり、UBI Microは入口対策ではなく、侵入後の攻撃チェーンを短くするための対策です。
CVE対応対象を減らすという効果
UBI Microの効果は、侵入後の道具を減らすことだけではありません。
もう1つ重要なのが、CVE対応対象を減らすことです。
アプリケーションが使っていないOSパッケージであっても、イメージに含まれていれば脆弱性スキャンの対象になります。
たとえば、アプリが curl を使っていない場合でも、イメージに curl が入っていれば、curl やその依存ライブラリのCVEが検出される可能性があります。
その場合、本当に使っていないのか、起動スクリプトや運用手順で使っていないか、削除できるのか、更新が必要なのか、残す場合どう扱うのかを確認する必要があります。
つまり、アプリの動作には関係しないプログラムでも、入っていればCVE対応上の大荷物になることがあります。
UBI Microは、この大荷物を減らすための選択肢でもあります。
フル版からUBI Microに変えると何が強くなるのか
「どれくらい安全になるのか」を、単純なパーセントで言うのは難しいです。
アプリケーションの脆弱性、設定、ネットワーク、権限、Secret管理によって結果が変わるためです。
ただし、フル版/UBI Standard系のようなイメージと比較すると、侵入後に攻撃者が最初から使える道具箱を小さくできる と説明できます。
| 観点 | フル版/UBI Standard系 | UBI Micro | 攻撃封じ込め上の意味 |
|---|---|---|---|
| OSツール | 比較的多い | 最小限 | 侵入後の偵察・調査に使える道具が減る |
| パッケージマネージャー | YUM/DNF系スタックを含むことがある | なし | 侵入後に正規経路で追加ツールを入れにくい |
| 追加パッケージ | 入れやすい | ビルド時に明示が必要 | 実行イメージへの後付けや環境差分を抑えやすい |
| CVE対象 | 多くなりやすい | 少なくしやすい | 脆弱性対応の対象を絞りやすい |
| デバッグ容易性 | 高い | 低い | 運用者にも攻撃者にも便利な道具を減らす |
| 侵入防止 | アプリ次第 | アプリ次第 | UBI Microだけでは入口は塞がない |
| 侵入後の行動制限 | 弱くなりやすい | 強くしやすい | 標準装備でできることを減らす |
言い換えると、UBI Microを使う価値は、「攻撃されなくなる」ことではありません。
価値があるのは、次の点です。
- 侵入後に標準状態で使えるOSコマンドを減らせる
- パッケージマネージャーによる追加導入を難しくできる
- 本番イメージに何が入っているかを確認しやすくできる
- 脆弱性スキャンの対象を減らせる可能性がある
- 攻撃者にとっても、運用者にとっても「便利すぎる」本番コンテナを避けられる
この整理にすると、UBI Microの効く範囲を過大評価せずに済みます。
フル版からUBI Microへ変える意味は、「脆弱性がゼロになる」ことではありません。
意味があるのは、侵入後に攻撃者が使える道具箱を小さくできる ことです。
UBI Microだけでは封じ込めは完成しない
UBI Microで、侵入後に使える道具を減らすことはできます。
しかし、これだけでは封じ込めは完成しません。
たとえば、次のようなことはUBI Micro単体では十分に防げません。
- アプリケーションが外部へ通信できる
- 一時ディレクトリにファイルを書ける
- Secretや環境変数を読める
- ServiceAccountに強い権限がある
- PVCに不正ファイルを書き込める
- Podが長期間動き続ける
そこで、Kubernetes/OpenShift側の制御が必要になります。
UBI Micro
→ 侵入後に使えるOS道具を減らす
readOnlyRootFilesystem
→ 後から道具やファイルを置きにくくする
最小権限 / capability drop
→ コンテナ内でできる操作を減らす
NetworkPolicy / egress制御
→ 外部から道具を取る、横展開する通信を絞る
Pod再作成
→ コンテナ内に残った一時的な汚染を消す
OpenTelemetry / logs / metrics
→ アプリケーションの処理経路、例外、遅延、外部呼び出しの変化を見る
一時診断Pod / 基盤側診断
→ DNS、IP疎通、経路、NetworkPolicy、DBや他アプリへの到達性を確認する
この組み合わせで考えると、UBI Microは「軽量化」ではなく、侵入後の封じ込めを設計するための部品になります。
Kubernetes/OpenShiftで組み合わせたい設定
ここでは、UBI Microと一緒に検討したいKubernetes/OpenShift側の設定を整理します。
1. ルートファイルシステムを読み取り専用にする
securityContext:
readOnlyRootFilesystem: true
ルートファイルシステムを書き込み不可にすると、コンテナ内に後からファイルを置きづらくなります。
ただし、アプリケーションが一時ファイルやログを書き込む場所は必要になることがあります。
その場合は、必要な場所だけを明示的にvolumeとして渡します。
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}
ポイントは、書き込みを全面的に許すのではなく、どこに書き込みを許すのかを明示する ことです。
2. 不要な権限を付けない
コンテナは、必要最小限のユーザーと権限で動かします。
securityContext:
runAsNonRoot: true
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
OSに直接インストールしていた頃は、root権限や広い権限を前提に運用していた環境もあるかもしれません。
コンテナでは、アプリケーション実行に必要な権限だけを与える方が扱いやすくなります。
3. NetworkPolicyで通信先を絞る
侵害後の行動を抑えるには、コンテナからどこへでも通信できる状態を避けることが重要です。
たとえば、アプリケーションが本当に通信する必要のある宛先だけを許可します。
アプリケーション → DB
アプリケーション → 必要な外部API
アプリケーション → OpenTelemetry Collector
UBI Microで curl がなくても、Javaアプリケーション自身が外部通信できる場合はあります。
そのため、通信制御はイメージだけではなく、基盤側で行う必要があります。
4. イメージタグだけでなくdigest固定を検討する
同じものを確実に動かすには、イメージの指定方法も重要です。
icr.io/appcafe/websphere-liberty:kernel-java21-openj9-ubi-micro
タグ指定は分かりやすい一方で、運用によっては同じタグが将来別の内容を指す可能性があります。
より厳密に固定したい場合は、digest指定を検討します。
icr.io/appcafe/websphere-liberty@sha256:...
これにより、「検証したイメージと実行しているイメージが同じか」を確認しやすくなります。
5. Podを作り直せる設計にする
OSに直接インストールしたサーバーでは、問題が起きるとログインして直す運用になりがちです。
コンテナでは、汚れた実行単位は捨てて作り直す、という考え方が重要です。
- Deploymentのローリング更新
- 再起動によるPodの再作成
- イメージ更新による再作成
- 障害時の切り戻し
Podを作り直すことで、コンテナ内に一時的に置かれたファイルや、汚染されたプロセスを消すことができます。
ただし、PVCなどの永続ボリュームに書かれたもの、外部に持ち出された情報、既に実行された外部操作は消えません。
Pod再作成は特効薬ではありませんが、長寿命の汚染プロセスを残しにくくする という意味では重要です。
補足：仮想パッチとは役割が違う
脆弱性対策には、WAF、API Gateway、Ingress Controller、サービスメッシュ、セキュリティ製品などで攻撃リクエストを検知・遮断する、いわゆる仮想パッチという考え方もあります。
仮想パッチは、アプリケーションやミドルウェアをすぐに修正できない場合に、外側で攻撃パターンを止めるための有効な手段です。
一方で、UBI Microで考えていることは少し違います。
UBI Microは、外からの攻撃リクエストを直接止めるものではありません。
また、アプリケーションやライブラリの脆弱性を修正してくれるものでもありません。
UBI Microで減らしたいのは、主に次の2つです。
- アプリケーション実行に不要なOSパッケージによるCVE対応対象
- 侵入後に攻撃者が使えるOSコマンドやパッケージマネージャー
つまり、仮想パッチは 「入口で止める」 対策です。
UBI Microは 「中に不要なものを入れない」 対策です。
どちらか一方で十分というより、役割が違います。
| 観点 | 主な対策例 |
|---|---|
| 入口で攻撃リクエストを止める | WAF、API Gateway、Ingress、仮想パッチ |
| 入ってしまった後の足場を減らす | UBI Micro、不要ツール削減、パッケージマネージャー削減 |
| 横展開や影響範囲を小さくする | NetworkPolicy、ServiceAccount、Secret管理、権限最小化 |
| 異常に気づく | ログ、Metrics、Trace、OpenTelemetry |
このように分けて考えると、UBI Microの位置づけが分かりやすくなります。
UBI Microは、入口対策の代わりではありません。
入口で止める対策と組み合わせたうえで、コンテナの中に置くものを減らし、CVE対応対象と侵入後に使われる道具を減らすための選択肢です。
RCE後に道具を持ち込まれる可能性も考える
UBI Microは、コンテナイメージに最初から入っている道具を減らします。
しかし、RCEが成立した場合、攻撃者が外部からスクリプトやバイナリを持ち込み、書き込み可能な場所に配置して実行しようとする可能性は残ります。
そのため、UBI Microだけで考えるのではなく、次のような対策と組み合わせます。
| 観点 | 対策例 |
|---|---|
| 外部から道具を取得させない | Egress制御、Proxy制御、NetworkPolicy、外向き通信先の制限 |
| 書き込み場所を限定する | read-only root filesystem、書き込み可能ディレクトリの限定 |
| 実行権限を絞る | non-root実行、権限最小化、不要なcapability削除 |
| 横展開を抑える | NetworkPolicy、Namespace分離、ServiceAccount/RBAC最小化 |
| 機密情報への到達を抑える | Secretの最小化、環境変数や設定ファイルの見直し |
| 侵入状態を残しにくくする | Podの再作成、ローリング更新、短命なコンテナ運用 |
| 異常に気づく | ログ、Metrics、Trace、Runtime Security、監査ログ |
ここで重要なのは、コンテナを「手で直しながら長く使うサーバー」として扱わないことです。
コンテナは、壊れたら中に入って直すものではなく、同じ定義から作り直すものです。
仮にRCE後に一時的なファイルを置かれたとしても、root filesystemが読み取り専用で、書き込み先が限定され、Podが再作成される構成であれば、コンテナ内への永続化は難しくなります。
ただし、Podを作り直せばすべて解決するわけではありません。
外部ストレージ、DB、Secret、ServiceAccount権限、外向き通信経路が残っていれば、影響は続く可能性があります。
そのため、UBI Microは次のような防御の一部として位置づけます。
- 入口で止める: WAF、Gateway、仮想パッチ
- 中に不要な道具を入れない: UBI Micro
- 外から道具を持ち込ませにくくする: Egress制御、NetworkPolicy
- 書かせない・実行させない: read-only root filesystem、non-root、権限最小化
- 横展開させない: Namespace分離、RBAC、ServiceAccount分離
- 残さない: Pod再作成、ローリング更新、Immutable Infrastructure
- 気づく: ログ、Metrics、Trace、Runtime Security
この整理を入れると、UBI Microを過大評価せずに済みます。
UBI Microは、RCEを無効化するものではありません。
また、外部から道具を持ち込まれる可能性をゼロにするものでもありません。
それでも、最初から入っている道具を減らし、外向き通信や書き込み先、実行権限、横展開経路を絞ることで、攻撃者が次の段階へ進むための手間を増やせます。
ネットワーク診断とアプリ観測を分ける
第4回・第5回で見た通り、アプリケーションの観測と、インフラ／ネットワークレイヤーの診断は分けて考えます。
アプリケーションの処理経路、例外、遅延、外部呼び出しはOpenTelemetry、ログ、Metricsで見ます。
一方で、DNS、IP疎通、経路、NetworkPolicy、Service / Endpoint / Ingress、DBや他アプリへの到達性は、一時診断Pod、Kubernetes/OpenShiftの情報、基盤側診断で確認します。
| 確認したいこと | 主な確認場所 | 補足 |
|---|---|---|
| DNS名前解決 | 同じNamespaceの一時診断Pod、CoreDNSログ、基盤側診断 |
dig / nslookup などを使う場合は診断用Pod側で行う |
| IP疎通・経路 | 一時診断Pod、Kubernetes/OpenShift、基盤側ネットワーク診断 |
ping / traceroute 相当の確認はアプリコンテナに常備しない |
| NetworkPolicyの影響 | 一時診断Pod、Kubernetes/OpenShift設定、基盤側診断 | 通信が許可されているかをネットワーク層で確認する |
| DBホストへの到達性 | 一時診断Pod、必要に応じたTCP接続確認 | アプリの代わりに同じNamespaceからDBホストへ到達できるか確認する |
| 他アプリ・外部APIへの到達性 | 一時診断Pod、HTTP/TLS確認、基盤側診断 | アプリの代わりに同じNamespaceから通信経路を確認する |
| アプリがDBや外部APIを実際に使えているか | Readiness Check、アプリログ、OpenTelemetry Trace | アプリケーション層の確認として扱う |
| 処理経路・例外・遅延 | OpenTelemetry、Metrics、ログ | OpenTelemetryの主な出番 |
一時診断Podは、本番アプリコンテナにくっつけるものではありません。
本番アプリコンテナのプロセスやファイルシステムを直接変更せず、同じNamespaceから見たDNS、Service、DB、他アプリ、外部APIへの通信を確認するための一時的な診断手段です。
この分担により、本番アプリコンテナには診断ツールを常備せず、必要なときだけ管理された方法でネットワーク層の調査を行えます。
OpenTelemetryで「怪しい」を見つけられるか
アプリ観測とインフラ診断を分けたうえで、OpenTelemetryが役立つのはアプリケーションの振る舞いの変化を見る場面です。
たとえば、普段とは違う外部呼び出し、例外の増加、応答時間の悪化、特定APIの失敗などをTrace、Metrics、ログから確認します。
第5回で見た通り、OpenTelemetryで扱う中心は、アプリケーションが実際に処理したリクエスト、外部呼び出し、例外、レイテンシの変化です。
一方で、DNS、IP疎通、経路、NetworkPolicyのようなインフラ／ネットワークレイヤーの確認は、一時診断Pod、Kubernetes/OpenShiftの情報、基盤側診断で扱います。
つまり、ここでは次のように役割を分けます。
- アプリケーションの処理経路、例外、遅延、外部呼び出しを見る: OpenTelemetry、ログ、Metrics
- DNS、IP疎通、経路、NetworkPolicyを見る: 一時診断Pod、Kubernetes/OpenShift、基盤側診断
- Service、Endpoint、Ingress、Pod状態を見る: Kubernetes/OpenShift
- DBや他アプリへの到達性を見る: 一時診断Pod、必要に応じたTCP/HTTP/TLS確認
OpenTelemetryは、UBI Microと組み合わせると便利です。
ただし、OpenTelemetryはフォレンジック製品でも、侵入検知製品そのものでもありません。
主な役割は、アプリケーションの振る舞いの変化に気づくこと です。
メモリが増えたら侵害なのか
メモリ使用量の変化だけでは、侵害とは言えません。
LibertyやJVMでは、次のような理由でメモリ使用量は普通に変動します。
- トラフィック増加
- キャッシュの利用
- Full GC前後の見え方
- クラスロード
- JITコンパイル
- ネイティブ領域の使用
- 一時的な高負荷
不正な処理や持ち込まれた道具によってメモリ使用量が増える可能性はあります。
ただし、メモリだけで判断すると誤検知が多くなります。
メモリは、単独で侵害判定に使うのではなく、他の信号と組み合わせて見るのが現実的です。
組み合わせて見る信号
OpenTelemetryやログで見るなら、たとえば次のような信号が候補になります。
- 普段呼ばれないURLへのアクセス
- 4xx / 5xx の急増
- 例外種類の変化
- コマンド起動失敗のようなエラー
- ファイル書き込み失敗
- 外部呼び出し先の増加
- 通常のリクエスト量と相関しないCPU上昇
- レイテンシの異常な増加
- コンテナ再起動の繰り返し
- Readiness / Livenessの失敗増加
たとえば、次のような組み合わせは調査のきっかけになります。
普段ない外部ホストへの通信
+ 5xxの増加
+ 説明しづらいCPU上昇
+ ファイル書き込みエラー
これでも、即座に侵害と断定するわけではありません。
ただし、調査すべき兆候として扱えます。
UBI Microの効果を確認する観点
ここでは、ここまでの考え方を確認する観点として、UBI Minimal版とUBI Micro版を比較するときに見るポイントを整理します。
完璧なセキュリティ基盤を作る必要はありません。
まずは、UBI Microで何が変わるかを小さく確認します。
1. UBI Microで起動する
この例では、公式Libertyコンテナイメージに含まれる configure.sh を使います。
configure.sh は、server.xml に定義されたLiberty featureをもとに、必要なfeatureをイメージに追加するためのヘルパースクリプトです。
FROM icr.io/appcafe/websphere-liberty:kernel-java21-openj9-ubi-micro
COPY --chown=1001:0 server.xml /config/
COPY --chown=1001:0 target/app.war /config/apps/
RUN configure.sh
まずは起動確認だけで十分です。
2. UBI Minimalと比較する
同じアプリケーションをUBI Minimalでもビルドし、次を比較します。
- イメージサイズ
- 脆弱性スキャン結果
- 起動ログ
- 追加パッケージの有無
- OSコマンドの有無
3. OSコマンドの有無を確認する
例として、次のようなコマンドが存在するか確認します。
which sh
which curl
which wget
which ping
which ps
which netstat
which microdnf
which dnf
UBI Microでは、こうした道具が前提にならないことが分かります。
4. 読み取り専用ファイルシステムを試す
securityContext:
readOnlyRootFilesystem: true
runAsNonRoot: true
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
これで起動しない場合は、アプリケーションがどこへ書き込もうとしているかを確認します。
必要な場所だけvolumeを割り当てます。
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}
5. 通信先を一覧化する
アプリケーションが通信する相手を整理します。
- DB
- 認証基盤
- 外部API
- メッセージング基盤
- OpenTelemetry Collector
- ログ収集基盤
この一覧が、NetworkPolicyやファイアウォール設定の材料になります。
6. コンテナに入らず状態を見る
最低限、次を確認します。
kubectl logs <pod-name>
kubectl describe pod <pod-name>
kubectl get events
OpenShiftの場合：
oc logs <pod-name>
oc describe pod <pod-name>
oc get events
可能であれば、OpenTelemetryで1つのAPIだけTraceを出してみます。
検証で見るポイント
手元の検証では、次のうちいくつかが分かれば十分です。
- UBI Microで起動できるか
- UBI Minimalとのサイズ差、スキャン結果差はどうか
- 追加パッケージが不要か
- どのOSコマンドが存在しないか
-
readOnlyRootFilesystemの適用可否 - 書き込みが必要な場所
- 不要なLinux capabilityを外せるか
- コンテナに入らずログで状態を確認できるか
- Health Checkでアプリケーションの起動状態・準備状態を確認できるか
- OpenTelemetryで処理経路、例外、遅延、外部呼び出しを確認できるか
- ネットワークレイヤーの確認を、一時診断Podや基盤側診断で実施できるか
これらは、いきなり本番利用を決めるためのものではありません。
まず、UBI Microで「何が変わるのか」を手元で確認するための材料です。
まとめ
UBI Microは、すべての脅威を防ぐものではありません。
ネット越しの入口、たとえばWebアプリケーション、API、管理エンドポイント、依存ライブラリ、設定ミスは、UBI Microだけでは防げません。
これらは、アプリケーション修正、依存更新、認証認可、管理エンドポイントの非公開化、ネットワーク制御で対応します。
それでも、UBI Microには大きな価値があります。
攻撃が成立した後に、攻撃者が次に行う 「調べる」「道具を入れる」「広げる準備をする」 という段階を進めにくくできます。
UBI Microを使う理由は、CVE対応対象を小さくすること と 侵入後に使われる道具を減らすこと です。
フル版からUBI Microへ変える意味は、脆弱性がゼロになることではありません。
意味があるのは、侵入後に攻撃者が使える道具箱を小さくできる ことです。
さらに、読み取り専用ファイルシステム、最小権限、NetworkPolicy、Pod再作成、OpenTelemetryを組み合わせることで、単なる軽量化ではなく、侵入後の封じ込めを設計しやすくなります。
UBI Microを使うということは、単に小さなイメージを選ぶことではありません。
本番コンテナに何を入れないか。
侵害後に何をさせないか。
異常をどう外から見るか。
この3つを考えるきっかけになります。
参考情報
- 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
- Red Hat Docs: Types of container images
- Kubernetes Docs: Configure a Security Context for a Pod or Container
- Kubernetes Docs: Network Policies
- Open Liberty Docs: Collect logs, metrics, and traces with OpenTelemetry