
MySQLを実行するDockerコンテナ(LXC)があります。 Dockerの基本的なアイデアは通常「コンテナごとに1つの実行プロセス」なので、MySQLバイナリをターゲットとするAppArmorプロファイルを定義すると適用されますか?これをテストする方法はありますか?
答え1
まず、cgroupはシステムの他のアプリケーションとアプリケーションを分離するためには使用されません。リソースの使用とデバイスアクセスの管理に使用されます。さまざまな名前空間(PID、UTS、マウント、ユーザー...)は、いくつかの(制限された)分離を提供します。
さらに、Dockerコンテナ内で起動されたプロセスは、実行中のAppArmorプロファイルを管理できない可能性があります。現在のアプローチは、コンテナを起動する前に特定のAppArmorプロファイルを設定することです。
Dockerのlibcontainer実行ドライバがサポートしているようです。コンテナ用のAppArmorプロファイルの設定ただし、ドキュメントに例や参照が見つかりません。
明らかにAppArmorもこれをサポートしています。UbuntuのLXC。
アプリケーション用のAppArmor構成ファイルを作成してコンテナ内でプロセスを開始する前に、LXC / libcontainer / Docker / ...がロードされていることを確認する必要があります。
この方法で使用されるプロファイルは強制的に適用され、これをテストするには違法アクセスを試みて失敗することを確認する必要があります。
この場合、バイナリと実際に実行された構成ファイルの間にリンクはありません。コンテナでこの設定ファイルを使用するには、Docker / LXCに明示的に指示する必要があります。 MySQLバイナリ用の設定ファイルを作成すると、コンテナではなくホストでのみ実行が適用されます。
答え2
答えはおそらく「いいえ」です。
これUbuntuサーバーガイド項目LXCあなたの正確な問題についてほとんど議論し、次のように述べました。
コンテナ内のプログラムはもはや制限できません。たとえば、MySQLはコンテナプロファイル(ホスト保護)で実行されますが、MySQLプロファイル(コンテナ保護)には入れることはできません。
悪用による副作用を防ぐためのより良いオプションは、コンテナを実行するユーザーを制限し、悪用を使用することです。ユーザー名カーネルの特性。しかし、docker
私が知っている限り、現在はサポートされていませんuserns
。
この場合、ホストの観点からMySQLは権限のないユーザーとして実行されますが、コンテナ内で必要に応じてroot
MySQLiptables
をホストの外部ポートにバインドできます。