Dockerコンテナーの攻撃面の強化/削減
主に静的にコンパイルされたgolangアプリケーションなどのマイクロサービスを実行するために、強化されたDockerインスタンスを設定したいと思います。私が探しているのは、ホストOSを不正なコンテナから保護し、コンテナを互いに保護することです。以下のシナリオで状況をまとめてみました。
シナリオ：
Alpine Linux（busyboxベースのOS）などの最小限のOSを実行するサーバーがあり、SElinuxとgrsecがインストール、アクティブ化され、正しく構成されています。
このサーバーでは、2つのコンテナー、AとB、ボリュームVを実行するDockerインスタンスを実行します。
コンテナーAには、パブリックインターネット（WebアプリまたはパブリックAPI）にネットワーク化された、依存関係のない静的にコンパイルされたアプリケーションが含まれています。このアプリケーションには、任意のコード実行/アップロード/完全リバースシェルのような、考えられないほどの大きなバグが含まれています。このコンテナは、アップロード先、データベースなどとしてボリュームVにもネットワーク接続されています。
ホストOSには、ルート時にのみ読み取ることができるフラグが含まれています（SElinuxによって適用されます）。
コンテナBにはフラグとアプリケーションも含まれていますが、外界との接続はありません。
攻撃者：
- 人間は、アプリケーションの大きなバグを知っています。
- 彼はフラグを取得したいと考えています。 Vのデータは重要ではありません。
- 彼はスパイ機関ではありませんが、それでも高度なセキュリティ専門家です。
- 知らないゼロデイにアクセスできるかもしれません。
仮定：
- Linuxカーネルにはバグがありますが、それをカバーするにはgrsecで十分です。 grsecが非アクティブ化されていない限り、攻撃ベクトルになることはできません
- GrsecとSElinuxにはバグがなく、設定ミスもありません。
- コンテナー内のユーザールートはコンテナー外のルートです（多分いつの日かこれが真実ではなくなるかもしれません...）
- Dockerは実際のDockerです。既知のバグはありませんが、過去のバグの影響を受けており、再び発生する可能性があります。
- 将来の調査のためのログシステムはすでに適切に設定されています。
目標：
- フラグを保護します。 Dockerにはバグがあると想定しているため、おそらく不可能です。
- 攻撃対象を減らす。
- 攻撃者の生活を困難にします。
- 攻撃者がフラグを取得しようとした場合にトリガーされるアラームを設定します。できれば彼がなんとか入手する前に。
質問：
- 私の仮定はどれほど現実的ですか？
- これらの目標をどのように達成しますか？
- 私の次の提案はどのように商品ですか？
- Dockerに対する一般的なセキュリティアドバイスはありますか？
私の提案：
- ユーザーがAに書き込むことができず、ユーザーがVでファイルを実行できないように、SElinuxを構成します。
ユーザーランドのない、最小限のDockerイメージを使用します。何かのようなもの：
FROM scratch COPY app / ENTRYPOINT ["/app"]アプリを実行する前に特権を昇格させます。 （それを行うための適切な方法が何かわからない...）
- 偽のbusyboxユーザーランド？
/bin/sh、/bin/ls、またはそのようなものを呼び出そうとすると、アラームをトリガーするもの。
強化ガイドラインについては、CISベンチマークを参照してください。 Dockerの現在のCISベンチマークは here にあります。これらは、ベースライン強化の業界標準として受け入れられています。また、Linuxなど、Webサーバー、DBなどのガイドラインも提供します。