1. Podmanユーザー・ガイド
  2. セキュリティに関する推奨事項

10 セキュリティに関する推奨事項

セキュリティに関する推奨事項とガイドラインに従って、インフラストラクチャとコンテナ化されたアプリケーションの安全性を確保します。

Podmanのコンポーネントのベスト・プラクティス

悪用を減らすために環境のインフラストラクチャ内のすべてのレベルでセキュリティ・ガイドラインに従ってください。環境内で使用されるコンポーネントごとにベスト・プラクティス・ガイドラインに従ってください。

コンテナ化では同じホスト上で実行されているアプリケーション間でリソースを分離できますが、分離が完了していないと、コンテナから切り離されたり、同じホストで実行されている他のコンテナに影響を与えるような方法でコンテナが悪用される可能性があります。組織内に様々なテナンシがある場合や、様々な顧客が同じインフラストラクチャを使用している場合は、より完全な分離を実現し、重大なデータ侵害の発生を防ぐために様々なホストまたは様々な仮想マシンでコンテナを実行することが不可欠です。

ホスト

  • ホスト・カーネルとオペレーティング・システム・ソフトウェアの定期的な更新

    問題が解決されると、カーネルおよびオペレーティング・システム・ソフトウェアのセキュリティ・パッチとバグ修正がリリースされます。最新のソフトウェア更新で、オペレーティングシステムを最新の状態に保ちます。システムで最新のソフトウェア・チャネルまたはリポジトリをサブスクライブします。定期的なDNF更新操作を実行します。また、Kspliceを使用してシステム・ソフトウェアを最新の状態に保つことを検討してください。

  • 最小限のオペレーティング・システムを使用しセキュリティのベスト・プラクティスに従っていることの確認

    可能な場合は、最小オペレーティング・システム・インストールを使用し、Oracle Linux 8: システム・セキュリティの強化で説明されているセキュリティのベスト・プラクティスにそれが従っていることを確認します。最も重要なことは、同じシステムで実行されているサービスの数を減らすことです。理想的なのは、常駐する他のすべてのサービスをPodmanで管理されているコンテナ内に移動するか、それらを全体的に他のシステムに移動することです。これは、コンテナが破損した場合に損害を抑えるのに役立ちます。

  • オペレーティング・システムとカーネルの安全性の定期的な精査

    安全性と潜在的な脆弱性についてオペレーティング・システムを定期的に精査することを怠らないでください。

  • 最適なセキュリティ機能セットを提供する成熟したシステム・コンポーネントの使用

    セキュリティおよび機能に関する既知の問題がすべて解決されるように、カーネルなどのすべてのシステム・コンポーネントを最新の状態に保つことをお薦めします。Unbreakable Enterprise Kernel (UEK)を使用している場合は、カーネル・ネームスペース、プライベート・ネットワーキング、制御グループなどのカーネルベースの機能が成熟し、信頼性が高くなり、テストされた回数が多くなるように、そのOracle Linuxリリース用の入手可能な最新世代のUEKを使用することを検討してください。

  • Linuxセキュリティ・モジュールの使用

    可能な場合は、ホスト上で適切なセキュリティ・モジュールを使用します。たとえば、強制モードでSELinuxを実行して、実行しているコンテナ・イメージからホストを保護します。また、ボリューム・マウントの使用時に、複数のコンテナの間、またはコンテナとホスト・システムの間でSELinuxセキュリティ・コンテキストを共有する必要がある場合は、-zオプションの使用を検討してください。これは、コンテナをホストと同じSElinuxコンテキストで評価するために非rootユーザーとしてコンテナを実行する場合に役立ちます。ボリュームを実行中コンテナのみに限定するには、-Zオプションを使用します。詳細は、「コンテナ・マウントの設定」を参照してください。

Podmanイメージ

  • イメージが検証済の信頼できるソースから得られることの確認

    Podmanイメージが、信頼できるレピュテーションがある認証されたソースから取得され、未変更のままデプロイされることを確認してください。例については、「署名付きイメージに対するPodmanの構成」を参照してください。

    リモート・ソースからイメージをプルする場合は、接続が保護されており、プル・リクエストにHTTPSを使用していることを確認してください。セキュアでなく、TLSで保護されていないイメージ・レジストリは使用しないでください。

    Podmanイメージは、可能なかぎり、イメージ提供元の監督された信頼できるコレクションに由来し、それに基づいている必要があります。

  • 確実に再現可能なイメージの作成

    Containerfileを使用して新しいイメージを構築する場合は、セキュリティのためにベース・イメージとインストール済ソフトウェアを確認します。セキュリティの脆弱性を確認したベース・イメージとソフトウェアが新しいイメージで使用されるようにするには、次のようにします。

    • イメージのContainerfileにおいてベース・イメージに固定バージョンを指定します。

    • イメージのContainerfileのビルド・ステップにおいて、パッケージのプルに固定バージョンを指定します(なお、依存関係の依存関係は、引き続き信頼性の問題になるある可能性があります)。

    • ビルド・ステップでのパッケージのプルに信頼できる検証済のソースが使用されていることを確認します

  • イメージにインストール済のパッケージの最小化

    新しいイメージ・ビルドには不要なパッケージをインストールしないでください。Containerfileを確認して不要なインストール・ステップを削除し、イメージがその機能のみに限定されるようにします。

Podmanコンテナ

  • root以外のユーザーでのコンテナの実行

    Podmanでは、Podmanコンテナを実行するホスト・ユーザーとして、各コンテナが実行されます。ホスト・ユーザーは、rootユーザーでもroot以外のユーザーでもかまいません。ほとんどセキュリティでは、root以外のホスト・ユーザーでコンテナを実行します。

  • メモリー使用量とCPU使用率が制限されたコンテナの実行の検討

    メモリーとスワップ・メモリーについて-mと--memory-swapオプションを、およびCPUについて-cオプションを使用して、コンテナのメモリー使用量とCPU使用率を制限することを検討してください。

  • コンテナの再起動の制限

    制御できないコンテナに起因する潜在的なサービス拒否を防ぐには、コンテナの作成時または実行時に、--restart=on-failure:Nオプションを使用してコンテナの再起動を制限します。

  • コンテナのリソース使用率の監視

    Podmanは、メモリー使用量、CPU時間、I/Oおよびネットワーク使用率など、コンテナ・リソースの使用状況を監視する機能を備えています。コンテナのリソース使用率を調べてパフォーマンス、エラー検出および異常な動作を確認します。リソースの使用、疑わしいトラフィック、予期しないユーザー・アクティビティなど、異常なアクティビティがないかリアルタイムにリソース使用状況を監視できるツールの使用を検討してください。

  • コンテナ・ファイル・アクセスの制限

    コンテナの作成および実行時には、--read-onlyフラグまたは-v <host dir>:<container dir>:roオプションを使用して、コンテナ・ファイル・アクセスを制限します。コンテナ・アプリケーションが書き込むためのボリュームを明示的に作成し、これらのボリューム内のファイルへの変更を監視します。コンテナの書込みアクセス専用のボリュームにスプロールがないか確認し、定期的にクリーン・アップするようにします。次の例は、:roオプションを使用してホスト・フォルダまたはファイルがコンテナに対して読取り専用になるようにホスト・ディレクトリをマウントする方法を示しています。 
    podman run -v /host_directory_to_be_mounted:/target_container_directory:ro oraclelinux:8

    前述の例では、host_directory_to_be_mountedはボリュームとしてマウントされるホスト・ディレクトリおよびファイルであり、target_container_directoryはホスト・ディレクトリがマウントされるコンテナ上のディレクトリです。

    コンテナ実行時に機密のホスト・システム・ディレクトリをマウントしないでください。

    • /

    • /boot

    • /dev

    • /etc

    • /lib

    • /proc

    • /sys

    • /usr

  • コンテナの安全性の定期的な確認

    コンテナの安全性チェックの自動化や、コンテナ内の変更の監視に役立つツールの使用を検討してください。

    ホスト・システムから不要なイメージやコンテナを体系的に削除して、イメージやコンテナのスプロールを回避し、セキュリティ精査を回避する可能性がある古い未使用のイメージやコンテナが誤って使用されるのを防ぎます。Podmanの自動更新機能を使用してイメージの新バージョンの有無のチェック、および影響を受けるコンテナの自動的な再デプロイのプロセスを自動化することを検討してください。

  • コンテナ内のカーネル機能について

    Oracle Linuxでは、rootユーザーが、機能と呼ばれる個別の単位に分割されます。デフォルトでは、次のカーネル機能がコンテナに付与されます。

    • CHOWN

    • DAC_OVERRIDE

    • FSETID

    • FOWNER

    • NET_RAW

    • SETGID

    • SETUID

    • SETFCAP

    • SETPCAP

    • NET_BIND_SERVICE

    • SYS_CHROOT

    • KILL

    デフォルトでは、次の重要なカーネル機能がコンテナから削除されます。

    • SYS_TIME

    • MKNOD

    • NET_ADMIN

    • SYS_MODULE

    • SYS_NICE

    • SYS_ADMIN

    • AUDIT_WRITE

    コンテナの起動時に--privilegedオプションを使用しないでください。これは、それによって、そのコンテナをホスト(削除された機能、制限されたデバイス、読取り専用マウント・ポイントおよびボリュームなど)から分離するセキュリティ機能が無効になるためです。

  • コンテナ内のカーネル・ファイル・ハンドルとプロセス・リソースを制限するオプションについて

    コンテナを作成および実行するときは、--ulimitオプションを使用してカーネル・リソースを制限するか、Podmanサービスの起動時に--default-ulimitを使用してコンテナのデフォルトを設定します。

  • コンテナからのネットワーク・アクセスを制限するオプションについて

    コンテナのネットワークを実行する場合は、ホストにポートを公開するときに、コンテナによるリスニング対象のネットワーク・インタフェースに攻撃対象領域が少なくなるように、ポートをバインドするインタフェースのIPアドレスを指定します。Podmanでは、-pまたは--publishオプションの使用時にIPアドレスを指定しないと、デフォルトですべてのインタフェース(0.0.0.0)に公開されます。

    コンテナ内でSSHを実行しないでください。

    コンテナ内で特権ポート(1024未満)をマップしないでください。

    コンテナの起動時または実行時に、コンテナに--net=hostモード・オプションを使用しないでください。このオプションは、コンテナにローカル・システム・サービスへの完全なアクセス権限を付与するため、安全ではありません。

  • コンテナ内のシステム・コールを制限するオプションについて

    Podmanコンテナでは、デフォルトで、/usr/share/containers/seccomp.jsonファイル内で指定されているシステム・コールに基づいて、コンテナで使用可能になるシステム・コールが制限されます。このリストはほとんどのコンテナと互換性があるため、システム・コールを追加する必要はありません。

  • コンテナとホスト・ネームスペースの共有の禁止

    コンテナの起動時または実行時に、PIDやIPCネームスペースなどのホスト・ネームスペースを共有しないでください。

  • コンテナへのホスト・デバイスの公開の禁止

    コンテナの起動時または実行時に、ホスト・デバイスをコンテナに公開しないでください。

コンテナ化されたアプリケーション

  • コンテナ化されたアプリケーション内でのカーネル・コールの最小化

    カーネルはコンテナ間で共有されるため、カーネル・コールはホスト・システム上で実行されている他のコンテナに対するリスクを増大させます。コンテナ化されたアプリケーション内では、可能なかぎり、カーネル・コールが使用されないようにしてください。

  • root以外のユーザーでのコンテナ・アプリケーションの実行

    コンテナ化されたアプリケーションがroot以外のユーザーとして実行されるようにします。UIDはホスト間で共有されるため、コンテナ内のrootユーザーはホスト上のrootユーザーです。

  • コンテナ化されたアプリケーションでのsetuidおよびsetgidの使用の削除または最小化

    ほとんどのアプリケーションにsetuidバイナリやsetgidバイナリは必要ありません。できれば、そのようなバイナリは無効にするか削除してください。そうすることで、権限エスカレーション攻撃に使用される可能性がなくなります。setuidまたはsetgid権限フラグを持つバイナリを検出した場合は、それらを完全に削除するか、権限フラグを削除して、バイナリ上のこれらの権限に関連付けられているリスクを排除します。

  • コンテナ化されたアプリケーションを非永続的なものにする設計

    可能なかぎり、アプリケーションはステートレスでロール可能、可能であれば即時移行できるマイクロサービス・コンテナ・アプリケーションになるように設計します。自身の設計でないアプリケーションを使用する場合は、コンテナ内で実行するソフトウェアを選択する際に、このアプローチを考慮してください。この品質を保つと、システムの侵害や不慮の事態が発生している間やその後にサービスを管理する場合に役立ちます。