【Day 48】非rootユーザー実行（セキュリティ強化とパーミッション管理） 〜デフォルトroot実行のコンテナエスケープ脅威を排除！.NET 8の標準非特権ユーザー「app」とボリューム権限トラブル完全攻略〜
「あなたが動かしているコンテナの実行ユーザー、意識したことはありますか？もし『何も設定していない』なら、それはサーバー全域をAdministrator権限で晒しているのと同じです！」
前回の講義（Day 47）では、イメージサイズを90%削減しシェルすら持たない「.NET Chiseled / Alpine」によるアタックサーフェス最小化を学びました。
そして今回のDay 48で立ち向かうのは、コンテナセキュリティにおいて最も重大でありながら、最も見落とされがちな「非rootユーザー実行（Non-root Execution）」です！
Dockerコンテナは「独立した箱」に見えますが、OSカーネルはホストマシンと共有しています。コンテナ内部でroot（UID 0）として動いているプロセスは、カーネルから見れば「ホストOSのrootそのもの」です。
万が一Webアプリに脆弱性があれば、コンテナの壁を突き破ってホストOSの全権を掌握される「コンテナエスケープ」の致命傷につながります。
本講義では、.NET 8で劇的に進化した公式の非rootユーザー「app（UID 1654）」の標準仕様から、エンジニアが実務で必ず頭を抱える「ボリュームマウント時の Permission Denied トラブル」の根本解決まで、徹底的に深掘り解説します！
📌 本日のアジェンダ（講義目次）
- 第1章：なぜコンテナのroot実行は危険なのか？ 〜コンテナエスケープとWindows Admin常時運用の罠〜
- 第2章：コンテナエスケープの脅威と「多層防御」の考え方 〜Linuxカーネル共有の現実〜
- 第3章：.NET 8で激変した「app」ユーザー標準仕様 〜UID 1654とポート8080への移行〜
- 第4章：現場で最もハマる「Permission denied」！ボリュームマウントとUID/GIDの壁を突破する
- 第5章：実践！非root対応の完全なDockerfile & Docker Compose設計
- 第6章：CIで非rootを強制！全社セキュリティポリシーの自動検査
- 第7章：本日のまとめと次回予告
1 なぜコンテナのroot実行は危険なのか？ 〜コンテナエスケープとWindows Admin常時運用の罠〜
Windows Serverやオンプレミスサーバーの管理経験がある方なら、誰しもが知っている大原則があります。
「IISのアプリケーションプールや日常のWebサービスを、Domain AdminsやローカルAdministrator権限で動かす運用者は絶対にいない」ということです。
Windowsでは、IIS専用の低特権アカウント（IIS_IUSRS や NetworkService）を使い、万が一WebアプリにSQLインジェクションやリモートコード実行（RCE）の脆弱性があっても、Windowsのシステム全域が乗っ取られないように制限するのが常識でした。
ところが、いざDockerコンテナの世界に来ると、多くの開発現場で驚くべき光景を目にします。
「Dockerfileに特に何も書かず、デフォルトの最高権限であるroot（UID 0）のままWebアプリを動かしている」のです。
「でも、コンテナはホストから隔離されているから、コンテナの中がrootでも外側には影響ないのでは？」と疑問に思うかもしれません。
結論から言うと、その認識は極めて危険な誤解です。
- カーネルはホストと100%共有されている：コンテナはVM（仮想マシン）のように独立したOSカーネルを持っていません。コンテナ内のプロセスがUID 0（root）である場合、Linuxカーネルから見れば「ホストOSのUID 0」として扱われます。
- コンテナエスケープによるホストOS乗っ取り：カーネルの脆弱性、Dockerランタイムの不具合（runcの脆弱性など）、あるいは不適切なマウント（
/var/run/docker.sockやホストの重要ディレクトリ）が存在する場合、root権限を持つ攻撃者は容易にコンテナの境界を突破してホストOSの全権を奪います。 - ホスト側ファイルの破壊・改ざん：ボリュームマウント（Bind Mount）されたホスト側のファイルに対して、root権限で何でも書き込み・削除ができてしまうため、設定ファイルやソースコードの汚染事故が発生します。
2 コンテナエスケープの脅威と「多層防御」の考え方 〜Linuxカーネル共有の現実〜
セキュリティの世界には「多層防御（Defense in Depth）」という鉄則があります。
「アプリケーションのコードに絶対にバグや脆弱性はない」と言い切ることは不可能です。サードパーティのNuGetライブラリやフレームワークに未知の脆弱性（ゼロデイ脆弱性）が潜んでいる可能性は常にあります。
仮に、Webアプリが攻撃者に侵入され、コンテナ内で任意のコマンドを実行されたとしましょう。
このとき、「コンテナ内のプロセスがrootか、非rootか」によって、被害の規模は天と地ほど変わります。
| 攻撃シナリオ | root実行コンテナ（危険） | 非root実行コンテナ（安全） |
|---|---|---|
| OSパッケージの改ざん | apt等でハッキングツールを自由に追加可能 |
システム変更権限がなく実行拒否（Permission denied） |
| パスワード/システムファイル閲覧 | /etc/shadow や機密ファイルを無制限に閲覧・書換 |
一般ユーザーにはアクセス権がなく遮断 |
| コンテナ脱出（エスケープ） | Linux Capabilitiesを悪用してホストOSを乗っ取り | 特権が剥奪されているためエスケープ不能 |
| ホストマウントファイルの保護 | ホスト側のroot所有ファイルを自由に削除・破壊 | 許可されたデータディレクトリ以外は一切触れない |
非rootユーザーでプロセスを起動しておけば、攻撃者は侵入できたとしても、手足をもがれた状態になります。これが「最小特権の原則（Principle of Least Privilege）」の真髄です。
3 .NET 8で激変した「app」ユーザー標準仕様 〜UID 1654とポート8080への移行〜
.NET 7以前の時代、C#エンジニアがDockerコンテナを非root化しようとすると、地味に面倒な作業が必要でした。
公式イメージがroot前提で作られていたため、Dockerfileの中で RUN useradd -u 1000 appuser のように自前でユーザーを作成し、パーミッションを設定しなければならなかったのです。
さらに厄介だったのが「Webサーバーの待ち受けポート」でした。
Linuxの仕様上、1024番未満のポート（ウェルノウンポート）をリッスンするにはroot権限（または CAP_NET_BIND_SERVICE 機能）が必要です。
ASP.NET Coreの従来の標準ポートは 80 番だったため、非rootユーザーに切り替えた途端にポート80をバインドできず、コンテナが起動時にクラッシュするという罠がありました。
この歴史的課題を一挙に解決したのが、.NET 8で導入された「非rootユーザー改革」です！
- 標準非rootユーザー「
app」の事前登録：.NET 8以降の全公式イメージ（Debian、Ubuntu、Chiseled、Alpine）に、あらかじめ ユーザー名app/ UID:GID1654:1654が定義されています。自前でuseraddを実行する必要は一切ありません。 - 標準リッスンポートが
8080（非特権ポート）に変更：環境変数ASPNETCORE_HTTP_PORTS=8080がデフォルト設定され、1024番以上の非特権ポートでリッスンするようになりました。これにより、非rootユーザーのままで何のエラーもなくWebサーバーが起動します。 - Dockerfileの末尾に
USER appを書くだけで完了：たった1行追加するだけで、完全に非特権化された安全な本番コンテナが完成します。
4 現場で最もハマる「Permission denied」！ボリュームマウントとUID/GIDの壁を突破する
「よし、じゃあDockerfileに USER app を追加してデプロイしよう！」
そう意気込んだエンジニアが、ほぼ100%の確率で直面する恐ろしいエラーがあります。
Unhandled exception. System.UnauthorizedAccessException: Access to the path '/app/logs' is denied.
at System.IO.FileSystem.CreateDirectory(String fullPath)
at Microsoft.Extensions.Logging.FileLoggerProvider..ctor()
そう、悪名高き「Permission denied（アクセス拒否）」エラーです！
コンテナを非root化すると、ログ出力ディレクトリやユーザーアップロード画像の一時保存フォルダなどに書き込もうとした瞬間、例外が発生してコンテナが即死します。
なぜ Permission denied が起きるのか？（メカニズム）
Linuxのファイルシステムにおいて、権限判定は「ユーザー名（appやubuntu）」ではなく、「UID（ユーザー識別番号）」によって厳格に行われます。
- ホスト側で
mkdir ./logsを作成すると、そのディレクトリの所有者はホストOSのユーザー（UID 1000など）または管理者（UID 0）になります。 - このディレクトリを
-v ./logs:/app/logsでコンテナにバインドマウントします。 - コンテナ内で動いているC#アプリは、.NET 8の非rootユーザー
app（UID 1654） です。 - UID 1654のユーザーから見ると、所有者がUID 1000やUID 0のフォルダに対して「書き込み権限（write permission）」が与えられていません。
- その結果、
Access to the path is deniedでクラッシュしてしまうのです！
パーミッションエラーを根絶する3大解決アプローチ
- Dockerfile内で事前に所有権を渡しておく（推奨）：
マルチステージビルドの最終ステージで、あらかじめ必要な書き込みディレクトリ（
/app/logsなど）を作成し、所有権をapp:app（UID 1654）に変更しておきます。# root権限の段階でディレクトリを作成し所有権をappに付与 USER root RUN mkdir -p /app/logs && chown -R app:app /app/logs USER app - ビルド成果物のCOPY時に所有権を指定する：
COPY命令のデフォルトは root 所有になってしまいます。--chown=app:appを付与することで、バイナリや設定ファイルの所有権をappユーザーに統一します。COPY --from=build --chown=app:app /app/publish . - Docker Volume（名前付きボリューム）を活用する：
ホストのディレクトリを直接貼るBind Mountではなく、Dockerが管理するNamed Volume（
docker volume create log_data）を使用すると、初回マウント時にコンテナ側のディレクトリ所有権（UID 1654）がそのままボリュームに初期化されるため、権限エラーが発生しません。
5 実践！非root対応の完全なDockerfile & Docker Compose設計
それでは、ここまでのセキュリティ知識をすべて凝縮した、ASP.NET Core 8/9 本番用マルチステージDockerfileの完全な設計を見てみましょう。
# ========================================== # ステージ1: ビルド環境（SDKイメージ） # ========================================== FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build WORKDIR /src # キャッシュ最適化：csprojを先にコピーしてNuGet復元 COPY ["MySecureApi.csproj", "./"] RUN dotnet restore "MySecureApi.csproj" # ソースコードをコピーしてReleaseビルド＆発行 COPY . . RUN dotnet publish "MySecureApi.csproj" -c Release -o /app/publish /p:UseAppHost=false # ========================================== # ステージ2: 本番ランタイム（Chiseled / 非root） # ========================================== FROM mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled AS final WORKDIR /app # .NET 8標準の非特権ポート8080を指定 EXPOSE 8080 ENV ASPNETCORE_HTTP_PORTS=8080 # 【超重要】所有権を標準非rootユーザー「app」に設定して成果物をCOPY COPY --from=build --chown=app:app /app/publish . # 【超重要】実行ユーザーを非rootの「app」に切り替え USER app ENTRYPOINT ["dotnet", "MySecureApi.dll"]
コンテナが本当に非rootで動いているかを検証する
コンテナを起動した後、本当にroot権限が剥奪されているかをコマンドで確かめてみましょう。
# コンテナを起動 $ docker run -d -p 8080:8080 --name secure-api my-secure-api:latest # 通常のUbuntu/Debianイメージの場合、whoami や id を実行 $ docker exec secure-api whoami app $ docker exec secure-api id uid=1654(app) gid=1654(app) groups=1654(app)
このように、uid=1654(app) と表示されれば検証成功です！
コンテナ内部でOSの管理領域や重要ファイルに手を出す権限は完全に奪われています。
6 CIで非rootを強制！全社セキュリティポリシーの自動検査
いくら「非rootで動かしましょう」と口頭やドキュメントでルールを決めても、開発者がうっかり USER 命令を書き忘れてしまっては意味がありません。
GitリポジトリとGitHub Actionsを活用して、「root実行のDockerfileが含まれるプルリクエスト（PR）は自動でCIを落とす」というガードレールを構築しましょう。
# .github/workflows/docker-security-lint.yml name: Docker Security Lint on: pull_request: paths: - '**/Dockerfile*' jobs: check-non-root: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Hadolint による Dockerfile 静的解析 uses: hadolint/hadolint-action@v3.1.0 with: dockerfile: Dockerfile # DL3002: Last USER should not be root を強制 failure-threshold: warning
このCIワークフローを導入すれば、Dockerfileの最後の USER 命令がrootのままだったり、USER の記述が漏れている場合、Hadolint（Dockerfile専用のLinter）が DL3002: Last USER should not be root というエラーを出してPRのマージを即座にブロックします。
セキュリティの標準化は、人間の注意深さに頼るのではなく、「GitとCIによる自動化」で担保するのが現代ソフトウェアエンジニアリングの基本です。
7 本日のまとめと次回予告
🎯 本日の重要ポイント総括
- コンテナのroot実行はOS全域を危険に晒す：コンテナはホストとLinuxカーネルを共有しているため、UID 0（root）のまま動かすとコンテナエスケープからホストOSを乗っ取られる重大リスクがある。
- 最小特権の原則を徹底する：万が一アプリケーションに脆弱性があっても、非rootユーザーで動いていればOSの改ざんやエスケープを物理的に封じ込めることができる。
- .NET 8の「app」ユーザー（UID 1654）を活用する：公式イメージに最初から登録されており、標準ポートも非特権な
8080に変更されているため、USER appと書くだけで安全に運用できる。 - パーミッションエラーはUIDの整合で解決：ホストとコンテナのUID不一致による Permission Denied は、事前
chownやCOPY --chown=app:app、Named Volumeの活用で美しく解決する。 - HadolintでCI自動検査：ルールを人の手作業に依存させず、GitHub Actionsで非rootを強制するパイプラインを標準化する。
NEXT LECTURE
次回【Day 49】脆弱性スキャナ「Trivy」によるコンテナセキュリティ診断 〜CIパイプラインでCVE脆弱性を検知・自動ブロックする DevSecOps 実践〜
非root化と極小化でコンテナを強固に防御した次は、コンテナイメージに含まれるパッケージやNuGetの「既知の脆弱性（CVE）」を炙り出すセキュリティスキャンに挑みます！
オープンソースのデファクトスタンダード「Trivy」をGitHub Actionsに組み込み、危険な脆弱性が1つでもあればPRを自動却下するDevSecOpsの鉄壁ゲートウェイを構築しましょう！次回もお楽しみに！
コメント
コメントを投稿