Kubernetes ランタイムのセキュリティ

過去 10 年間、コンテナ化されたワークロードと Kubernetes (K8) がソフトウェアの世界を席巻してきました。 残念ながら、Kubernetes がエンタープライズ アーキテクチャの定番となるにつれて、脅威アクターにとって価値の高い標的になります。

コンテナのセキュリティ全般、特にKubernetes のセキュリティは、今日の企業のセキュリティ体制の基本的な側面です。 この記事では、K8s セキュリティの最も重要な側面の 1 つである Kubernetes ランタイム セキュリティについて、K8s ランタイム セキュリティの 7 つの重要なベスト プラクティスを含めて説明します。

デモをリクエストする 詳細はこちら

Kubernetes ランタイム セキュリティとは何ですか?

Kubernetes ランタイム セキュリティは、 Kubernetes上で実行中のコンテナ ワークロードを保護する一連のツール、プラクティス、およびテクノロジです。

言い換えれば、Kubernetes ランタイム セキュリティは、ワークロード保護とコンテナ セキュリティのサブカテゴリです。 Kubernetes ランタイム セキュリティは、コンテナのインスタンス化から終了までのセキュリティを扱います。 つまり、ランタイムセキュリティには、コンテナがルートとして実行されるかどうか(実行すべきではない)などが含まれますが、コンテナイメージのスキャンなどのトピックは対象としていません。

Kubernetes ランタイムのセキュリティの課題とリスク

現在、K8 上では非常に多くの種類のアプリケーションが実行されているため、コンテナや Kubernetes のランタイム セキュリティ リスクに対応する万能のセットはありません。 ただし、ほとんどの企業に共通する Kubernetes ランタイム セキュリティの一連の課題があります。

Kubernetes 上のランタイム コンテナのセキュリティに関連する 4 つの一般的なセキュリティ リスクを次に示します。

  • 権限昇格:攻撃者が K8s 環境にアクセスし、より高い特権を持つユーザー (root など) に昇格することは、教科書的な Kubernetes ランタイム セキュリティの脅威です。
  • K8 とコンテナの脆弱性: コンテナ自体に悪意がない場合でも、既知のエクスプロイトを備えた CVE に対して脆弱であることがよくあります。

ネイティブ Kubernetes ランタイム セキュリティ ツール

Kubernetes は、実行時のリスクを制限できる限られたネイティブ ツールとコントロールのセットを提供します。 これらには以下が含まれます:

  • シークレット: K8s シークレットは、API キーやパスワードなどの情報を保存するデータ オブジェクトです。 Secretsを使用すると、企業は機密データをイメージやPodの仕様から遠ざけることができます。
  • アドミッション コントローラー: K8s アドミッション コントローラーを使用すると、企業は Kubernetes API エンドポイントの変更 (読み取りではなく) を制限できます。
  • ネットワーク ポリシー: Kubernetes ネットワーク ポリシーは、ネットワーク層とトランスポート層でポリシーを強制する従来の ALLOW および BLOCK ファイアウォール ルールに似ています。
  • 監査ログ: 監査ログは、クラスターで発生したアクションの詳細を提供します。 たとえば、API アクティビティを監査できます。 これらのログにより、悪意のある動作の分析と検出が可能になります。
  • RBAC : ロールベースのアクセス制御 (RBAC) を使用すると、管理者はエンティティのロールに基づいて K8s API アクセスを制限できます。

ネイティブの Kubernetes ランタイム セキュリティ ツールは、リアルタイムの脅威検出などのユースケースに直接対応していないため、多くの企業は、より堅牢なワークロード保護ツールに依存しています。

7 Kubernetes ランタイム セキュリティのベスト プラクティス

これら 6 つの Kubernetes ランタイムのベスト プラクティスは、企業が多くの K8 セキュリティ脅威を制限するのに役立ちます。

  1. コンテナをルートとして実行しない: コンテナをルートとして実行すると、脅威アクターが権限昇格攻撃を受ける可能性があります。 rootとして実行しないだけで、多くの脅威を軽減できます。
  2. コンテナー構成の監査と自動化: シークレットにあるべきデータを公開したり、データベースインスタンスをインターネットに接続したりすることは、侵害につながる可能性のある構成ミスの例です。 Infrastructure as Code (IaC) を使用して構成を監査し、構成のデプロイメントを自動化することは、リスクを制限する優れた方法です。
  3. ネットワーク層をロックダウンする: K8s ネットワーク ポリシーや RBAC に加えて、 IPS/IDSや NGFW などのネットワーク セキュリティ ツールは、脅威がワークロードに到達する前に検出して阻止できます。 さらに、企業は可能な限りDockerデーモンソケットの公開を避ける必要があります。
  4. 特権モードを避ける: コンテナーを root として実行しないのと同様に、企業は –privileged フラグを使用してコンテナーを実行しないようにする必要があります。 –privilegedフラグを使用すると、コンテナはシステムを安全に保つためのさまざまなチェックをバイパスできます。
  5. 可能な限り読み取り専用ファイルシステムを使用する: 読み取り専用ファイルシステムは、脅威アクターがコンテナのファイルシステムにマルウェアを直接書き込むことを防ぎます。 これにより、脅威アクターがエクスプロイトを実行する能力が制限される可能性があります。
  6. 信頼できるコンテナイメージのみを実行する: パブリックリポジトリは、管理者が侵害されたイメージをインスタンス化するとすぐに、コンテナランタイム環境のセキュリティを脅かす可能性があります。 信頼できるコンテナイメージを使用することで、企業はパブリックイメージリポジトリからのイメージのリスクを抑えることができます。
  7. カーネル レベルを保護する: SELinux、cgroups、AppArmor などのソリューションは、Kubernetes ランタイム セキュリティに保護層を追加できます。 たとえば、AppArmorは、さまざまなカーネルリソースへのアクセスを制限するポリシーを定義して、アプリがアクセスできないはずのシステム機能を利用するリスクを軽減できます。

シフトレフトにより効果的な Kubernetes ランタイム セキュリティを補完

もちろん、セキュリティの側面は孤立して存在しません。 ランタイム セキュリティは重要ですが、セキュリティはコンテナーがインスタンス化されるかなり前から開始されます。 前述の Kubernetes ランタイム セキュリティのベスト プラクティスのいくつかはこれを明確にしており、シフトレフト セキュリティの概念がその点を明確にしています。 開発ライフサイクルの早い段階でセキュリティを統合し、堅牢なランタイム保護を行うことで、両方の長所を活かすことができます。

CloudGuard Workload保護による Kubernetes ランタイム セキュリティ

CloudGuard Workload Protection は、企業が Kubernetes コンテナーとサーバーレス機能に必要とする集中管理によるエンドツーエンドの保護を提供するプラットフォームです。

CloudGuard Workload Protection の利点は次のとおりです。

  • アプリ全体のゼロトラスト セキュリティ: Kubernetes コンテナ、API、サーバーレス機能の保護。
  • セキュリティ構成の自動展開:セキュリティ ポリシーを自動的に定義して展開し、人的エラーや構成ミスのリスクを軽減します。
  • マルチクラウドおよびハイブリッド クラウドのサポート:クラウドとオンプレミス全体でセキュリティを確保します。
  • コンテナイメージのスキャン: 脆弱なコンテナや悪意のあるコンテナをインスタンス化される前に検出します。
  • リアルタイムのインシデント検出: 悪意のある動作をインテリジェントに検出することで、脅威が被害を受ける前に阻止できます。
  • サーバーレス機能の動作防御:サーバーレス セキュリティにはコンテキストが必要であり、動作防御はサーバーレス機能の悪意のある使用をインテリジェントに検出できます。

CloudGuard Workload Protection の詳細については、今すぐコンテナ セキュリティ デモにサインアップしてください。 デモでは、IaC スキャン、自動化されたランタイム保護、すべてのクラウドにわたるセキュリティなど、主要なコンテナ セキュリティの概念について学びます。

×
  Feedback
このウェブサイトは、機能性と分析およびマーケティングの目的でクッキーを使用しています。 このウェブサイトを引き続きご利用いただくことで、クッキーの使用に同意したことになります。 詳細については、 Cookie に関する通知をお読みください。
OK