MutatingAdmissionControllerを使用したKubernetesワークロードのランタイム保護 #aqua #コンテナ #セキュリティ #kubernetes #MutatingAdmissionController
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2020年11月11日に公開された「 Runtime Protection for K8s Workloads Using a Mutating Admission Controller 」の日本語翻訳です。
MutatingAdmissionControllerを使用したKubernetesワークロードのランタイム保護
Kubernetes はコンテナオーケストレータープラットフォームとして十分に採用されるまでに成熟してきました。しかし、管理とセキュリティを確保するのは複雑なままです。これを悪用しようとする悪質な攻撃者や、攻撃対象の増加と相まって、組織は Kubernetes アプリケーションのセキュリティを確保するための包括的なアプローチを実装しなければなりません。Aqua は Admission Controller などの Kubernetes ネイティブコントロールを活用し、Pod にサイドカーコンテナとして配備することで、Kubernetes ベースアプリケーションの、セキュリティ確保の複雑さを緩和することを目指しています。
Kubernetes ネイティブのコントロールを活用し、組織が可能な限りアプリケーションに近い所でセキュリティを実装できるよう支援することで、セキュリティチームと DevOps チームの間のギャップを埋めることができます。これを実現するために、Kubernetes Security Posture Management(KSPM)を導入しました。これは、Kubernetes インフラストラクチャのセキュリティポスチャを評価するのに役立つ新機能です。ポスチャ管理はあらゆる Kubernetes セキュリティプログラムの一部であるべきであり、ランタイムコントロールはそれを補完するために使用されるべきです。まずはクラスタが正しく設定されていることを確認し、さらに各クラスタに許可されるイメージを制御します。その上で疑わしい動作や潜在的な突破口を検出・防止するために、クラスタ上でのランタイム保護について考えてみましょう。
Kubernetes の Admission Controllers
Kubernetes ネイティブのランタイム保護について掘り下げていく前に、Kubernetes API に用意された重要な機能である Admission Controller、特に Webhook を使用して管理する仕組みについて理解する必要があります。Admission Controller は、Kubernetes の管理者がデフォルトでセキュアなデプロイメントを実装するのに役立つように設計されています。リソース制御からプロビジョニングまで多くの目的に利用でき、オブジェクトが永続化する前に Kubernetes API サーバへのリクエストをインターセプトするなどの、セキュリティ面でも機能します。
Admission Controller はクラスタ上で実行できるものを定義・カスタマイズするのに役立ち、Validate Webhook や Mutating Webhook、あるいはその両方を使用できます。この2つのタイプの違いは、Mutating Webhook は API サーバに送られたオブジェクトを変更してカスタムデフォルトを適用できるのに対し、Validating Admission Webhook はカスタムポリシーを実装するためのリクエストを拒否できます。つまり、Validate Webhook は (デプロイされた Pod のような)Kubernetesのオブジェクトを承認または拒否するために使用でき、Mutating Webhook はその設定を変更するために使用できます。
Kubernetes ネイティブセキュリティの活用
Kubernetes が業界のスタンダードとして登場して以来、Aqua のコンテナランタイム保護機能は、Kubernetes のネイティブ機能のいくつかを活用しながら、 Kubernetes の中でシームレスに動作しランタイムをコントロールしてきました。しかし、Kubernetes が本番環境へ広く利用されるようになり、攻撃対象が拡大しています。そのため組織は複雑化する環境に対処するため、より強固なランタイム保護コントロールを必要とし、それに伴う複雑さを回避する必要があります。
今日の一般的なセキュリティツールは、Kubernetes のワークロードを保護するためのエージェントとして特権コンテナを各ホスト・ノードにデプロイすることが一般的です。しかし一部の組織では、これがセキュリティ上の障害や運用上の制約となっています。そこで Aquaは、Kubernetes ワークロードに RuntimePolicy を強制する業界初の代替方法を導入します。Enforcers(ワークロードをセキュリティ保護するための Aqua のエージェント)を特権コンテナとして全ノードへデプロイする代わりに、Aqua Kube Enforcer をデプロイできるようになりました。Aqua Kube EnforcerはWebhooks を介して、Kubernetes Admission Controller の Validate Webhook と Mutating Webhook の両方を実装し強化されました。また、Envoy(一般的なハイパフォーマンスプロキシ)のデプロイ方法と似た方法で、Mutating Webhook により Kubernetes に最適化された Aqua の新たな機能である Pod Enforcer を非特権サイドカーコンテナとして Pod に注入します。これにより、Aqua のランタイム保護を Pod 内で実行しているコンテナに適用しながら、動的なポリシー変更を受け入れることができます。
Aqua の Kubernetes ランタイム保護
Aqua の新しいモデルでは、コンテナの DriftPrevention(Aqua の機能の一つ)・振る舞い制御・ネットワーク制御などの動的なランタイム保護を提供しながら、ノードのOS 特権を必要とせずに Kubernetes のデプロイを簡単に自動化できます。Aqua の Kubernetes ランタイム保護は、組織がデフォルトでセキュリティを実装し、Kubernetes クラスタのセキュリティガバナンスを強化するのに役立ちます。ホストコンポーネント・内部構成・管理 API・ワークロード(Pod)など、Kubernetes アーキテクチャ全体でホスト権限を必要とせずに容易にセキュリティを強化できます。
Admission Controllers と 可視性
Aqua Kube Enforcer は Kubernetes API Server の Validating Admission Controller として登録され、DevOps チームに Kubernetes クラスタの完全な可視性を提供します。また、ホスト・Namespace・および実行中のコンテナを検出し、SecOps ポリシーに従ってクラスタ内の Pod のデプロイを制御します。Kube Enforcer は Risk Explorer を介してクラスタ全体のコンテナイメージの検証と可視性を提供し、検出された実行中のコンテナのイメージを自動的に登録します。
エージェントレスな保護、円滑なデプロイメント
Aqua の新しい Kubernetes ランタイム保護機能は、自動化・柔軟性・スケールなどの Kubernetes の機能をサポートしながら、ランタイム保護のデプロイに発生する衝突を排除します。Kubernetes 自体を使用してセキュリティコントロールを Pod に展開するため、DevOps チームはデプロイ方法を何も変更する必要がありません。
全体的な Kubernetes セキュリティを実現する
動的な Admission Control と Pod サイドカーの組み合わせにより、Aqua はあらゆる潜在的なワークロードの脅威に対応する Kubernetes の「フロントドア」セキュリティを提供します。DevOps チーム は Pod の作成とデプロイメントのために、きめ細かい認証ポリシーを設定できます。Aqua Kubernetes ランタイム保護は、Kubernetes ワーカーノードとコントロールプレーン、および Pod とノードの間の分離を実現します。ノードに関係なくワークロードを計測するための粒度が向上し、ハードウェアを最適化する大規模な環境をサポートします。
Aqua の Kubernetes Security を使用することで、DevOps チームは Kubernetes インフラストラクチャの構成を簡単にセキュアにでき、セキュリティチームと連携してパイプライン全体にセキュリティポリシーを実装することで、より効果的に作業を進めることができます。
Aqua の Kubernetes Security Posture Management(KSPM)と新しいエージェントレスな Kubernetes ランタイム保護により、組織は Kubernetes ベースのアプリケーションを複数の脅威から守ります。同時に、ニーズに応じて適切なランタイム保護のデプロイメントモデルを自由に選択できます。
