はじめに (対象読者・この記事でわかること)

この記事は、Dockerを使ってAlmaLinux 8のコンテナ環境を構築し、その中でアプリケーションを開発・実行しているエンジニアや開発者を対象としています。特に、コンテナ内の一般ユーザー権限でcurlコマンドを実行した際に、予期せず失敗してしまう問題に直面した方、またはそのような問題が発生する可能性を懸念されている方におすすめです。

この記事を読むことで、AlmaLinux 8のDockerコンテナにおいて、一般ユーザーがcurlコマンドで外部リソースにアクセスできない原因を特定し、その具体的な解決策を理解することができます。これにより、コンテナ内でのネットワーク通信に関する問題を迅速に解決し、開発効率の向上に繋げることができるようになります。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。 * Dockerの基本的なコマンド操作（docker run, docker execなど） * Linuxの基本的なコマンド操作（ls, cd, catなど） * ネットワークの基本的な概念（HTTP/HTTPS、DNSなど）

Dockerコンテナ内の一般ユーザーでcurlが失敗する問題の概要

Dockerコンテナを利用した開発環境において、rootユーザーでは問題なくcurlコマンドが実行できるにも関わらず、コンテナ内で作成した一般ユーザーで実行すると「Connection refused」や「Could not resolve host」といったエラーが発生するケースがあります。この問題は、一見するとネットワーク設定に起因するように見えますが、実際にはコンテナ内のユーザー権限と、特定のネットワーク機能へのアクセス制限が関連していることが多いです。

AlmaLinux 8のような比較的新しいディストリビューションでは、セキュリティ強化のためにデフォルトで特定のシステムコールへのアクセスが制限されている場合があります。curlコマンドは、内部的にDNS解決やソケット通信といったネットワーク操作を行いますが、これらの操作の一部が一般ユーザー権限では実行できないように設定されていると、問題が発生します。特に、コンテナがホストOSのネットワーク名前空間を共有する際に、ユーザーIDマッピングやAppArmor/SELinuxなどのセキュリティ機構が影響を及ぼすことが考えられます。

この問題の背景には、コンテナの分離性を高めるためのセキュリティベストプラクティスが関係しています。コンテナ内でroot権限を無効化し、必要最低限の権限を持つ一般ユーザーでプロセスを実行することは、セキュリティリスクを低減するための重要な手法です。しかし、その一方で、本来root権限でしかアクセスできないはずのリソースやAPIに対して、一般ユーザーがアクセスしようとした際に予期せぬ問題が発生することがあります。

curlコマンド失敗の具体的な原因と解決策

AlmaLinux 8のDockerコンテナで一般ユーザーがcurlコマンドを使用する際に発生する問題は、主に以下の3つの原因が考えられます。それぞれの原因に対して、具体的な解決策を解説します。

原因1：DNS解決の問題

curlコマンドが外部のホスト名にアクセスできない場合、まずDNS解決に問題がないか確認する必要があります。コンテナ内でping google.comなどのコマンドを実行し、ホスト名がIPアドレスに正しく解決されるかを確認します。

解決策1：/etc/resolv.conf の設定確認と修正

Dockerコンテナは、通常、ホストOSの/etc/resolv.confをコピーして使用します。しかし、何らかの理由でこのファイルが正しく設定されていない、または参照できない場合があります。

  1. コンテナ内の/etc/resolv.confの内容を確認する: bash docker exec -it <container_name_or_id> cat /etc/resolv.conf nameserverディレクティブに有効なDNSサーバーのIPアドレス（例: nameserver 8.8.8.8）が記載されているか確認してください。

  2. DockerデーモンのDNS設定を確認する: Dockerデーモンが使用するDNSサーバーは、Dockerデーモンの設定ファイル（daemon.json）で指定できます。 bash # Dockerデーモン設定ファイルを確認 (パスは環境により異なる場合があります) cat /etc/docker/daemon.json もしdnsキーで特定のDNSサーバーが指定されている場合、それが利用可能であることを確認してください。

  3. コンテナ起動時にDNSサーバーを指定する: docker runコマンドで、--dnsオプションを使って直接DNSサーバーを指定することも可能です。 bash docker run --dns 8.8.8.8 ... <image_name>

原因2：ネットワーク機能へのアクセス権限不足

curlコマンドは、ソケット通信などのネットワーク機能を利用します。これらの機能へのアクセスが、ユーザー権限によって制限されている場合があります。特に、コンテナ内でsetuidやsetgidビットが設定されたプログラムや、特定のパーミッションが要求されるネットワークインターフェースへのアクセスが問題となることがあります。

解決策2：コンテナの実行権限とユーザー設定の見直し

  • rootユーザーで試す: まず、rootユーザーでcurlコマンドが正常に動作することを確認します。 bash docker exec -u root -it <container_name_or_id> curl <url> もしrootユーザーで動作し、一般ユーザーで失敗する場合、権限の問題である可能性が高いです。

  • capabilities の追加: Dockerでは、コンテナに付与するLinuxケーパビリティ（機能）を調整することで、権限問題を解決できる場合があります。CAP_NET_RAWやCAP_NET_ADMINなどが関連する可能性があります。 bash docker run --cap-add NET_RAW --cap-add NET_ADMIN ... <image_name> ただし、これらのケーパビリティの追加はセキュリティリスクを高める可能性があるため、必要最小限に留めるべきです。

  • コンテナ内のユーザー設定: AlmaLinux 8では、firewalldなどがデフォルトで有効になっており、これらが一般ユーザーからの特定のネットワークアクセスをブロックしている可能性も考えられます。コンテナ内のfirewalldの状態を確認し、必要であれば一時的に無効化してテストしてみてください。 bash # コンテナ内で実行 sudo systemctl status firewalld sudo systemctl stop firewalld （注：firewalldを停止する際は、コンテナのセキュリティポリシーを理解した上で行ってください。）

原因3：IPマスカレードやNATの設定不備（ホスト側）

コンテナからの通信は、ホストOSのネットワーク設定（IPマスカレードやNAT）を経由します。ホストOS側のファイアウォール設定や、Dockerデーモンが使用するブリッジネットワークの設定が不適切だと、コンテナからの通信がブロックされることがあります。

解決策3：ホストOSのネットワーク設定とDockerネットワークの確認

  • ホストOSのファイアウォール設定: ホストOSでfirewalldやiptablesが有効な場合、Dockerコンテナからのアウトバウンド通信（特にHTTP/HTTPSポート）を許可するルールが設定されているか確認してください。 bash # iptables の設定確認 (root権限で実行) sudo iptables -L -n -v # firewalld の設定確認 (root権限で実行) sudo firewall-cmd --list-all Dockerは通常、通信に必要なiptablesルールを自動的に追加しますが、カスタム設定や競合がある場合に問題が発生することがあります。

  • Dockerネットワークの確認: デフォルトのbridgeネットワーク以外を使用している場合、そのネットワーク設定が適切か確認してください。 bash docker network ls docker network inspect <network_name> カスタムネットワークを作成している場合は、そのネットワークのゲートウェイやサブネット設定がホストOSのネットワークと競合していないか確認します。

  • Dockerデーモンの再起動: ネットワーク設定の変更後、Dockerデーモンを再起動すると、設定が反映される場合があります。 bash sudo systemctl restart docker

具体的なエラー例とデバッグ手順

例1：curl: (7) Failed to connect to <host> port 80: Connection refused

このエラーは、指定したホストのポート80への接続が拒否されたことを意味します。

  1. コンテナ内から ping または telnet で確認: bash # コンテナ内で実行 ping <host> telnet <host> 80 pingが成功してもtelnetが失敗する場合、ポートレベルでのブロックが疑われます。

  2. ホストOSのファイアウォール設定を確認: ホストOS側で、Dockerのブリッジインターフェース（docker0など）からのアウトバウンド通信が許可されているか確認します。

例2：curl: (6) Could not resolve host: <host>

このエラーは、ホスト名をIPアドレスに解決できないことを意味します。

  1. /etc/resolv.conf の確認: 上記「原因1」の解決策に従って、DNSサーバーの設定を確認・修正します。

  2. コンテナ内でのnslookupまたはdigコマンド: bash # コンテナ内で実行 nslookup <host> dig <host> これらのコマンドで、DNSサーバーが正しく機能しているか、応答が得られるかを確認します。

デバッグのヒント:

  • strace の利用: curlコマンドがどのようなシステムコールを実行しているかを確認することで、問題の箇所を特定できる場合があります。 bash # コンテナ内でroot権限で実行 docker exec -it -u root <container_name_or_id> strace curl <url> straceの出力から、どのシステムコールでエラーが発生しているかを確認します。

  • コンテナの再作成: Dockerイメージに問題がある場合や、コンテナ作成時の設定ミスが原因の可能性もあります。クリーンな状態でコンテナを再作成し、同様の問題が発生するか確認します。

まとめ

本記事では、Dockerコンテナ（特にAlmaLinux 8）で一般ユーザーがcurlコマンドを実行する際に発生する、「Connection refused」や「Could not resolve host」といったエラーの原因と解決策について解説しました。

  • DNS設定の確認: /etc/resolv.confの正しさ、DockerデーモンのDNS設定、docker run時の--dnsオプションの利用。
  • ネットワーク権限の確認: Linuxケーパビリティ（CAP_NET_RAW, CAP_NET_ADMINなど）の追加、firewalldなどのコンテナ内サービスの設定。
  • ホストOSのネットワーク確認: ファイアウォール（iptablesなど）によるDocker通信の許可、Dockerネットワーク設定の確認。

これらの原因と対策を理解することで、コンテナ内でのネットワーク通信に関する問題を効率的にデバッグし、開発環境を安定させることができます。

今後は、よりセキュアなコンテナ環境を構築するためのユーザー権限管理や、ネットワークセキュリティ設定のベストプラクティスについても記事にする予定です。

参考資料