（コンテナ内で）rootにノーと言ってください

システム上のコンテナプロセスが実行できることを制御するために使用されるさまざまなセキュリティ対策について、私はいつも尋ねられます。これらのほとんどは、Opensource.comの以前の記事で取り上げました：

• Dockerコンテナは本当に安全ですか？
• Dockerに新しいセキュリティ機能を導入する
• 将来のDockerセキュリティ

上記の記事のほとんどすべては、システム上の特権プロセスがコンテナー内で実行できることを制御することに関するものです。例：コンテナでrootを実行し、それが発生しないようにするにはどうすればよいですか？

Linuxコンテナ

• Linuxコンテナとは何ですか？
• コンテナ用語の概要
• ダウンロード：Containers Primer
• Kubernetesオペレーター：コンテナオーケストレーションプラットフォームの自動化
• eBook：クラウドネイティブアプリを設計するためのKubernetesパターン
• Kubernetesとは何ですか？

ユーザー名前空間とは、コンテナー内で特権プロセスを実行することです。そのため、プロセスが発生した場合、コンテナーの外部では特権がなくなります。たとえば、コンテナ内のUIDは0（ゼロ）ですが、コンテナ外のUIDは5000です。ファイルシステムのサポートがないという問題のため、ユーザーの名前空間は万能薬ではありませんでした。今まで。

OpenShiftはRedHatのコンテナープラットフォームであり、Kubernetes、Red Hat Enterprise Linux、およびOCIコンテナー上に構築されており、優れたセキュリティ機能を備えています。デフォルトでは、コンテナーをrootとして実行することはできません。管理者はこれをオーバーライドできます。そうしないと、すべてのユーザーコンテナがrootになることなく実行されます。これは、単一のクラスターが複数のアプリケーションと複数の開発チームにサービスを提供する可能性があるマルチテナントのOpenShiftKubernetesクラスターで特に重要です。管理者がそれぞれに個別のクラスターを実行することは、常に実用的であるとは限りません。悲しいことに、OpenShiftに関する最大の不満の1つは、ユーザーがdocker.ioで利用可能なすべてのコミュニティコンテナーイメージを簡単に実行できないことです。これは、今日の世界のコンテナイメージの大部分がルートを必要とするためです。

これらすべての画像にルートが必要なのはなぜですか？

システム上でルートになる理由を実際に調べると、それらは非常に限られています。

ホストシステムを変更します：

• システムでrootになる主な理由の1つは、カーネルの構成を変更するなど、システムのデフォルト設定を変更することです。
• Fedora、CentOS、およびRed Hat Enterprise Linuxには、システムコンテナーの概念があります。 、atomicを使用してシステムにインストールできる特権コンテナです。 指図。それらは完全な特権で実行でき、カーネルだけでなくシステムも変更できます。 システムコンテナの場合 コンテナ画像をコンテンツ配信システムとして使用しており、実際にはコンテナの分離を求めていません。システムコンテナは、ほとんどのコンテナが実行するユーザーアプリサービスとは対照的に、コアオペレーティングシステムホストサービス向けです。
• アプリケーションコンテナでは、コンテナ内のプロセスがカーネルを変更することはほとんどありません。これはデフォルトでは絶対に必要ありません。

Unix / Linuxの伝統：

• オペレーティングシステムソフトウェアのベンダーと開発者は、rootが危険であるため、プロセスを実行することを長い間知っていました。そのため、カーネルは、プロセスをrootとして開始し、できるだけ早く特権を削除できるように、多くのLinux機能を追加しました。ほとんどのUID/GID機能を使用すると、Webサービスなどのプロセスをrootとして開始し、その後非rootにすることができます。これは、1024未満のポートにバインドするために行われます（これについては後で詳しく説明します）。
• コンテナランタイムは、そもそも非ルートとしてアプリケーションを起動できます。真実は知られているので、systemdもそうですが、過去20年間に構築されたほとんどのソフトウェアは、rootとして開始し、特権を削除することを前提としています。

ポートにバインド<1024

• コンピュータがほとんどなかった1960年代と1970年代に、非特権ユーザーが1024未満のネットワークポートにバインドできないことはセキュリティ機能と見なされていました。これを実行できるのは管理者だけなので、これらのポートでリッスンしているアプリケーションを信頼できます。 1024を超えるポートは、システム上のすべてのユーザーによってバインドされる可能性があるため、信頼できませんでした。これによるセキュリティ上のメリットはほとんどなくなりましたが、私たちはまだこの制限を受けています。
• この制限の最大の問題は、Webサーバーがポート80でリッスンするのが好きなWebサービスです。これは、apacheまたはnginxがrootとして実行を開始する主な理由は、ポート80にバインドしてからバインドできるようにするためです。非ルートになります。
• ポートフォワーディングを使用するコンテナランタイムは、この問題を解決できます。任意のネットワークポートでリッスンするようにコンテナを設定してから、コンテナランタイムにそのポートをホストのポート80にマップさせることができます。

このコマンドでは、podmanランタイムはapache_unprivを実行します ホストのポート80でリッスンしているマシン上のコンテナー。コンテナー内のApacheプロセスはルートではなく、apacheとして開始されました。 ユーザーであり、ポート8080でリッスンするように指示されました。

podman run -d -p 80:8080 -u apache apache_unpriv

または：

docker run -d -p 80:8080 -u apache apache_unpriv

コンテナイメージへのソフトウェアのインストール

• Dockerがdocker buildを使用してビルドコンテナを導入したとき 、コンテナのコンテンツは、配布用の標準パッケージソフトウェアにすぎませんでした。ソフトウェアは通常、rpmパッケージまたはDebianパッケージを介して提供されていました。さて、ディストリビューションはrootによってインストールされるソフトウェアをパッケージ化します。パッケージは、/etc/passwdの操作などを実行できることを期待しています。 ユーザーを追加してファイルを作成し、異なるUID/GIDを使用してファイルシステムにコンテンツを配置します。多くのソフトウェアは、initシステム（systemd）を介して起動し、rootとして起動し、起動後に特権を削除することも想定しています。
• 残念ながら、コンテナ革命から5年経った今でも、これは現状のままです。数年前、私はhttpdパッケージを取得して、root以外のユーザーによってインストールされていることを認識し、異なる構成にすることを試みました。しかし、私はこれにボールを落としました。パッケージャーとパッケージ管理システムに違いを理解してもらう必要があります。そうすれば、rootを必要とせずに実行できる優れたコンテナーを作成できます。
• この問題を修正するために今できることの1つは、ビルドシステムをインストールシステムから分離することです。 #nobigfatdaemonsに関する私の問題の1つは、Dockerデーモンが、コンテナーイメージを構築する場合と同じ特権でコンテナーを実行するようになることです。
• システムを変更するか、別のツール（Buildahなど）を使用して制約が緩いコンテナーを構築し、CRI-O / Kubernetes / OpenShiftを使用してコンテナーを本番環境で実行する場合、昇格された特権でビルドできますが、制約がはるかに厳しいコンテナ、またはできれば非ルートとしてのコンテナ ユーザー。

結論

コンテナで実行しているほとんどすべてのソフトウェアはしません ルートが必要です。 Webアプリケーション、データベース、ロードバランサー、ナンバークランチャーなどはしません ルートとして実行する必要があります。ルートをまったく必要としないコンテナイメージの構築を開始したり、非特権コンテナイメージに基づいてイメージを作成したりすると、コンテナのセキュリティが大幅に向上します。

コンテナ内でルートを実行することについては、まだ多くの教育を行う必要があります。教育がなければ、賢い管理者は悪い決定を下す可能性があります。