5

インターネットで見つけられるほとんどの Dockerfile は、root としてソフトウェアをビルドして実行します。これはみんなを怖がらせなければなりませんよね？...しかし、そうではないようです...

したがって、コンテナ内のルートはコンテナ外のルートとまったく同じであるため、コンテナー内であってもサーバーをルートとして実行することは危険です。

解決策の 1 つは、この tor リレーの例のように "USER" 命令を使用して Dockerfile を適切にビルドすることです。

別の解決策は、「linux ユーザー名前空間」を使用して、コンテナー内の UID/GID をコンテナー外の UID/GID に「マップ」することです。たとえば、コンテナー内のルート (uid=0) は、ホスト内の個人ユーザー アカウントにマップできるため、共有ボリュームで作成されたファイルには適切なアクセス許可が付与されます。

だから私の質問は次のとおりです。Docker のセキュリティに関しては、ベスト プラクティスは何ですか? 非ルートとしてコードを実行します (つまり、Dockerfile の USER 命令) ? または「ユーザー名前空間」を使用して？または、最終的に（または追加で） selinux および/または AppArmor を使用して？

ありがとう ：）

4

3 に答える 3

3

ソロモン・ハイクスの引用

こんにちは、私は Docker のメンテナーです。他の人がすでに示したように、これは 1.0 では機能しません。しかし、それはあったかもしれません。

現時点では、すぐに使える Docker が root 権限を持つ信頼できないプログラムを含めるのに適しているとは主張していないことを覚えておいてください。したがって、「1.0 にアップグレードしたか、乾杯してよかった」と考えている場合は、基になる構成を今すぐ変更する必要があります。apparmor または selinux の封じ込めを追加するか、信頼グループを別のマシンにマップするか、理想的にはアプリケーションへのルート アクセスを許可しないでください。

したがって、セキュリティを真剣に考えている場合、ベストプラクティスが名前空間と apparmor または selinux に当てはまる限り、そうです。そうは言っても、多くの人は（良くも悪くも）余分なトラブルに行くほど気にしていないので、多くの人がトラブルに行かないことがわかります. コンテナー内のファイル (特にボリュームとしてマウントされたファイル) に対するユーザーのアクセス許可の設定は、ときどき難しくなり、多くの人が余分なオーバーヘッドをスキップしてしまいます。

于 2014-12-24T16:34:05.557 に答える
1

SELinux、Apparmour、GRSEC に加えて、cgroupsはコンテナー リソースの使用を分離および制限するという追加の利点を提供します。これは、注意して構成されている場合、侵害されたコンテナーが別のコンテナーに影響を与えるのを防ぐのに役立ちます。参照

于 2014-12-25T05:39:41.600 に答える