コンテナセキュリティ – 新しいフロンティア (パート 2)

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

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

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

私たちは、クラウド、クラスター、コンテナ、コードの 4 つの C を考慮した階層化された多層防御アプローチを使用するという Kubernetes のアドバイスから始めて (それに基づいて構築する必要があると感じています)。また、セグメンテーションによってコンテナを侵害する脅威を封じ込める方法も検討する必要があると感じています。

この場合、私たちは5番目のCとして封じ込めを提案します。 

コンテナを保護するだけでなく、コンテナが悪用され、データセンター内で横方向に移動するための橋頭堡として使用されないようにする必要性については以前に説明しました。そこで封じ込めの必要性が重要になります。 

4 つの C に関する最初の Kubernetes ガイダンスを調べてから、封じ込めについて説明しましょう。

コンテナー

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

• スキャン: コンテナーをスキャンして既知の脆弱性を探します。CoreOSのClairのようなツールが役立つ場合があります。
• コンテナー イメージに署名する: Docker エンジンに組み込まれている 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クラスターに属する重要な構成ファイルとデータストアを表示できないようにします。

クラスター

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

封じ込め

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

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

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