IT用語集 2024/09/26

コンテナセキュリティとは？ 10分でわかりやすく解説

コラム

コンテナセキュリティは、コンテナそのものだけを守る話ではありません。イメージの入手元、レジストリ、実行時の権限、コンテナ間通信、ホストOS、Kubernetes などの設定まで含めて、脆弱性や設定ミスが広がらないように管理することです。最初に着手しやすく、効果も出やすいのは、使用するイメージの固定、脆弱性スキャンの停止条件の明確化、非root実行と特権付与の抑制、通信の許可範囲の明確化です。

コンテナセキュリティとは

コンテナセキュリティとは、コンテナ化したアプリケーションを、作成・保管・配布・実行・運用の各段階で保護するための管理と対策です。対象はコンテナ単体に限りません。イメージ、レジストリ、CI/CD、コンテナランタイム、ホストOS、オーケストレーション基盤まで含めて見直す必要があります。

コンテナとは

コンテナは、アプリケーションと、その実行に必要なライブラリや設定をイメージとしてまとめ、ホストOS上で分離して動かす仕組みです。Linux の namespaces や cgroups を利用するため、起動が速く、同じイメージを開発環境から本番環境まで持ち運びやすい利点があります。

一方で、VMのようにゲストOSを個別に持つわけではなく、ホストOSのカーネルを共有します。このため、イメージの不備だけでなく、過剰な権限付与、ランタイム設定、ホストOS側の脆弱性がそのまま影響範囲を広げることがあります。

どこがリスクになるか

リスク	内容
脆弱なイメージの利用	既知の脆弱性を含むベースイメージや依存ライブラリを取り込むと、同じ不備が複数の環境へ広がります。
過剰な権限設定	root実行、特権コンテナ、危険な Linux capability 付与、ホストソケットのマウントは、侵害後の権限拡大につながります。
分離の誤認	「コンテナだから安全」と見なすと、ネットワーク、権限、ホスト境界の設計が甘くなりやすくなります。
ランタイム／ホストOS起因のリスク	コンテナランタイムやホストOSカーネルの脆弱性、ノードの設定不備が、複数ワークロードへ波及することがあります。
サプライチェーンリスク	不正なイメージ改ざん、依存関係の混入、ビルド環境の汚染は、サプライチェーン攻撃の起点になります。

これらのリスクは単独で起きるだけではありません。自動デプロイ、共有レジストリ、複数チームでの運用が組み合わさると、短時間で広がりやすくなります。

優先度が上がりやすい場面

インターネットへ公開するサービスをコンテナで運用している
外部のベースイメージやOSS依存関係を多く取り込んでいる
CI/CDでデプロイ頻度が高く、変更の反映が速い
複数チームや複数環境で Kubernetes クラスタを共有している
機密情報を扱うAPI、バッチ、管理系ワークロードをコンテナ化している

コンテナのセキュリティ対策

対策は「イメージ」「配布」「実行」「通信」「ホスト」の順に並べると漏れにくくなります。

最初に優先したい4つの対策

使用するイメージを固定する
許可したベースイメージと配布元を決め、誰でも自由に外部レジストリから取得できる状態を避けます。
脆弱性スキャンに停止条件を設ける
スキャン結果を見るだけで終わらせず、どの条件でビルドやリリースを止めるかを決めます。
実行時の権限を削る
非root実行、特権コンテナの禁止、不要 capability の削減を標準にします。
通信先を絞る
コンテナ間通信、外部公開、管理プレーンへの到達性を、必要なものだけに限定します。

コンテナイメージの管理

コンテナセキュリティの起点はイメージです。どのイメージを使ってよいかが曖昧だと、後段の対策が機能しにくくなります。

信頼できるベースイメージを用途別に定め、社内標準イメージとして管理する
不要なパッケージやツールを入れず、最小構成を維持する
本番向けや再現性が必要なビルドでは、latest タグだけに依存しない
管理されたプライベートレジストリへ集約し、外部レジストリの直接参照を抑える
イメージ署名の検証、SBOM の生成・保管、レジストリアクセス制御を組み合わせる

タグは差し替え可能です。再現性や監査性を重視するなら、タグだけでなくダイジェスト固定も検討したほうが安全です。

脆弱性スキャンと停止条件の設計

脆弱性スキャンは、実施の有無よりも、結果をどう扱うかで差が出ます。重大度一覧を出すだけでは、運用の意思決定に使えません。

CIでイメージスキャンを実行し、基準を超えた場合はビルドやリリースを停止する
レジストリ登録時にも再スキャンし、公開後に判明した脆弱性を拾う
稼働中コンテナとイメージを突き合わせ、どの環境に影響があるかを追跡できるようにする
外部公開の有無、扱うデータ、実際の到達可能性で修正優先度を分ける

「ゼロ脆弱性」を一律の目標にすると、更新が止まりやすくなります。公開面が大きいワークロードと、閉域で限定利用するワークロードを同じ基準で扱わず、停止条件と例外条件を先に決めておくほうが運用しやすくなります。

実行時の権限設計

コンテナ実行時は、設定ひとつで危険度が大きく変わります。基本は最小権限の原則です。

root実行を避け、可能なら非rootユーザーで動かす
特権コンテナを原則禁止し、Linux capability は必要最小限に絞る
ファイルシステムを read-only にし、書き込み先は必要な領域だけに限定する
seccomp、AppArmor、SELinux などで許可する動作を制限する
ホストの機微情報やソケット（例：/var/run/docker.sock）を安易にマウントしない

例外を許す場合は、期限、代替策、レビュー担当を先に決めておく必要があります。例外が増えるほど、標準設定は崩れやすくなります。

ネットワーク到達性の制御

侵害後の被害を抑えるには、横展開を前提に通信を絞る必要があります。Kubernetes では NetworkPolicy を適用しない限り、Pod 間の通信が広く許可されたままになりやすいため、後付けではなく初期設計で考えるべきです。

対策	狙い
デフォルト拒否から始める	許可した通信だけを通す構成にし、不要な Pod 間通信を減らします。
公開面を絞る	Ingress、Load Balancer、WAF などで入口を整理し、管理系ポートを外部へ出さないようにします。
管理プレーンや補助サービスへの到達を制限する	DNS、メタデータサービス、Kubernetes API などへのアクセスを必要なワークロードに限定します。

ホストOSとコンテナランタイムの保護

コンテナはホストOSのカーネルを共有するため、ノード側の保護が弱いと、アプリ側だけ整えても防ぎ切れません。

ホストOSとコンテナランタイムの更新計画を作り、パッチ適用を遅らせない
ノードへのログイン経路を限定し、多要素認証や踏み台、監査ログを組み合わせる
不要なサービスや管理ポートを停止し、ノードの役割を明確にする
ノード上の不審プロセス、異常通信、ファイル改変を監視する

コンテナオーケストレーションとセキュリティ

単体コンテナの対策ができていても、Kubernetes の設定が緩いと被害は広がります。特に、APIアクセス、サービスアカウント、機密情報、Namespace境界、監査ログは確認が必要です。

Kubernetesで確認したい設定

項目	確認したい内容
RBAC	ユーザーやサービスアカウントごとに、必要な操作だけを許可しているか。cluster-admin 相当の権限が広がっていないか。
NetworkPolicy	Namespace内外の Pod 間通信を、許可が必要なものだけに絞れているか。
Secrets	機密情報を設定ファイルから切り離して扱えているか。あわせて etcd 暗号化、RBAC、参照範囲の制御ができているか。
Pod Security Admission	危険な Pod 定義を受け付けないよう、Pod Security Standards に沿った制約を適用しているか。

Kubernetes運用で優先したい項目

APIサーバーを直接公開しない
管理経路を限定し、アクセス元や認証方式を絞ります。
サービスアカウント権限を棚卸しする
不要な権限や横断権限を減らし、用途ごとに分けます。
Namespaceで境界を作る
開発／本番、チーム、機密度などで分離し、同じクラスタ上でも影響範囲を限定します。
持ち込みイメージの経路を制御する
許可されたレジストリ、署名検証済み、スキャン済みのイメージだけをデプロイ対象にします。
危険な設定をAdmissionで拒否する
特権コンテナや hostPath など、許容しない設定を自動で止めます。
監査ログとイベントを集約する
API監査ログ、クラスタイベント、ワークロードログを別々にせず、追跡できる形にまとめます。

監視と監査で見る点

アプリログ、コンテナログ、クラスタイベント、監査ログを一元化する
異常なプロセス生成、権限変更、外部通信など、実行時の不審な挙動を検知する
誰がいつ何を変更したかを追跡し、設定ドリフトを把握する
即時対応が必要なアラートと、調査対象のアラートを分ける

まとめ

コンテナセキュリティで先に押さえるべきなのは、イメージの固定、脆弱性スキャンの停止条件、実行時の最小権限、通信の制御です。Kubernetes を使う場合は、そこに RBAC、Secrets 管理、Pod Security Admission、監査ログを重ねます。単発の点検で終わらせず、イメージ更新、設定レビュー、監視の流れに組み込むことで、脆弱性や設定ミスの広がり方を抑えやすくなります。