コンテナセキュリティ — 新しいフロンティア (Part 2)

コンテナの使用を安全に保つための考慮事項に関する2部構成のブログシリーズ。

新しい次元のコンテナセキュリティ

コンテナがもたらす可能性のあるセキュリティ上の課題について概説しました 最初のブログ投稿で。そのため、コンテナのセキュリティについてどう考えるべきかという疑問が残ります。

私たちは、クラウド、クラスタ、コンテナ、コードという4つのCを考慮した、階層化された多層防御アプローチを使用するというKubernetesのアドバイスから始めて（そしてそれを基に）すべきだと考えています。また、コンテナを危険にさらす脅威をセグメンテーションで封じ込める方法を検討すべきだとも感じています。

そういうわけで、私たちは5番目のCとして封じ込めを提案します。

先ほど、コンテナを保護するだけでなく、コンテナがデータセンターの内部を横方向に移動する際の足掛かりとして悪用されないようにする必要性について説明しました。そこで、コンテインメントの必要性が出てきます。

4Cに関する最初のKubernetesガイダンスを調べてから、コンテインメントについて説明します。

コンテナ

Kubernetes でソフトウェアを実行するには、コンテナ内にある必要があります。そのため、Kubernetes では次のような一般的なセキュリティ上の考慮事項を概説しています。

• スキャン:コンテナをスキャンして既知の脆弱性がないか調べます。CoreOS の Clair のようなツールが役立つ場合があります。
• コンテナイメージへの署名:Docker Engine に組み込まれた Docker Content Trust を使用して、コンテナコンテンツの信頼性を維持します。IBM の Portieris プロジェクトは、適切に署名されたイメージに対してコンテンツの信頼性を強化するためのアドミッションコントローラーとして使用できます。
• ユーザー権限の制御:コンテナーの目的を達成するために必要最小限のオペレーティングシステム権限しか持たないユーザーをコンテナー内に作成するようにします。 

コード

アプリケーションコードレベルを調べてみると、Kubernetes のガイダンスには次のような点が挙げられます。

• TLS 経由のアクセスのみを許可:ファイアウォールの内側にあるネットワークサービス間も含め、転送中のすべてのものをデフォルトで暗号化するようにします。
• 通信のポート範囲を制限する:サービス上で絶対に不可欠なポートのみを公開します。
• 静的コードの分析:コードを解析して、潜在的に危険なコーディング手法がないか調べます。
• ダイナミック・プロービング攻撃のテスト:使用 OWASP ツール SQL インジェクション、CSRF などの一般的な攻撃を自動化します。

クラウド

各クラウドプロバイダーは、クラウドインフラストラクチャでコンテナワークロードを実行する方法に関する広範な推奨事項を提供しています。提供するセキュリティはクラウドプロバイダーによって異なる場合があり、ユーザーはこれらの推奨事項に細心の注意を払って従わなければなりません。一般的なクラウドプロバイダーへのリンクとセキュリティに関する推奨事項については、を参照してください。 https://kubernetes.io/docs/concepts/security/#the-4c-s-of-cloud-native-security。

一般的なガイダンスには以下が含まれます。

• ネットワークアクセスの制限:ほとんどのクラウドセキュリティプロバイダーが提供しています ネットワークセキュリティ アクセスコントロールリストの使用 — たとえば、AWSでは、ワークロードをグループに分割したり、グループごとにACLを設定したりできるセキュリティグループを用意しています。
• API アクセスの制限:理想的には、クラスターの管理に必要なサーバーだけが API サーバーにアクセスできる必要があります。
• Kubernetes クラスタ API へのアクセスを制限する:クラスタには、次のようなクラウドプロバイダーアクセスを提供するのが最適です。 最小権限の原則 管理に必要なリソースについて。AWS の Kops の例は以下にあります。https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles。
• 「etcd」へのアクセスを制限する:このディレクトリには、Kubernetes のクラウド設定ファイルが存在します。これらのファイルへのアクセスや変更には、必ず TLS を使用してください。
• すべてのドライブ、特に etcd ドライブを暗号化:権限のないユーザーが Kubernetes クラスターに属する重要な設定ファイルやデータストアを閲覧できないようにします。

クラスタ

• 以下を使用して、Kubernetes API へのアクセスをクラスターに制限します。 RBAC。
• クラスターを制御する API へのすべてのアクセスを認証します。
• etcd のすべてのデータを含め、クラスターで使用されるすべてのシークレットキーを暗号化します。
• ポッドのセキュリティ面の制御:ポッドセキュリティオブジェクトは、ポッドがシステムに受け入れられるために実行しなければならない一連の条件を定義します。
• リソース利用の制御:アプリケーションを実行する Kubernetes ノードは、信頼性とリソースのバランスを取るために互いに依存しています。そのため、これらのノードが使用するリソースの量を制限するポリシーが必要です。
• アクセス制御リストを使用して、ポッドへのすべてのネットワークポリシーを制御します。これは南北のセキュリティポリシーです。データセンター内のポリシーについては、以下の「コンテインメント」を参照してください。
• すべてのイングレスアクセスを TLS 経由に制限します。

コンテインメント

これで、コンテナから発生する侵害の拡大を防ぐ封じ込めの5番目のCにたどり着きます。封じ込めが最も効果的であるためには、いくつかの点を考慮する必要があります。

• 新しく作成されたコンテナをリアルタイムで検出します。
• 新しいコンテナワークロードの自動セグメンテーションが可能になるため、セキュリティは「誕生時」に自動的に適用されます。
• コンテナの可視性を他のコンピューティング環境と一緒に一元化することで、コンテナ化されたワークロードとベアメタル、仮想マシン、プライベートクラウドとパブリッククラウドの全体を一元的に把握できます。見えないものは保護できないからです。
• コンテナ全体やその他のすべてに統一されたポリシーを適用することで、環境に関係なく、統一されたポリシーでセグメント化できます。これにより、VM、ベアメタルサーバー、クラウド、コンテナのセグメンテーションに複数のポイントツールを使用する必要がなくなります。

コンテナに対する幅広い多層防御アプローチにより、組織はコンテナのセキュリティの実行可能性が保証され、さらに自信を持ってコンテナを導入できます。