Kubernetesにおけるランタイムセキュリティ脅威の管理

多くの管理者は、ランタイムセキュリティとは何か、なぜ重要なのかを理解しています。しかし、Kubernetesのセキュリティ戦略の一環として、ランタイムセキュリティを見落としたり、投資不足に陥ったりすることがよくあります。

その理由を理解するのは簡単です： Kubernetesは非常に複雑なシステムであり、権限へのアクセスやワークロードの分離を支援するために非常に多くの種類のネイティブツールを提供しているため、チームはクラスタ自体のセキュリティ確保に没頭するあまり、Kubernetesのランタイムセキュリティのことを忘れてしまうのです。

このギャップを埋めるために、この記事ではKubernetesのランタイムセキュリティがなぜ重要なのか、そしてランタイムの脅威からKubernetesを保護するためにどのようなツールが利用可能なのかを説明します。

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

Kubernetesのランタイムセキュリティとは、コンテナ（またはポッド）をコンテナ実行後のアクティブな脅威から保護することです。

ランタイムセキュリティは、コンテナがデプロイされた後に出現する可能性のある以下のようなさまざまな脅威からワークロードを保護するのに役立ちます：

• コンテナイメージ内に隠されたマルウェアの起動。
• コンテナが、コンテナランタイム、Kubernetes、またはホストOSのセキュリティバグを悪用して、アクセスできないはずのリソース（ストレージボリュームや外部バイナリなど）にアクセスする特権昇格攻撃。
• アクセス制御ポリシーのギャップやKubernetesのバグを悪用した攻撃者による不正なコンテナのデプロイ
• 実行中のコンテナが読み取ることができないはずの秘密情報やその他の機密情報への不正アクセス。ただし、不適切なアクセス制御設定や、特権の昇格を可能にするセキュリティ脆弱性のために、コンテナがアクセスできてしまう場合

理想とする完璧な世界であれば、このようなランタイム脅威は一切起こりません。なぜなら、私たちのアプリケーション・パイプラインとクラスタは、実行環境に脅威が侵入することがないように保護されているからです。また、厳格なアクセス制御を使用して各ワークロードが適切に隔離されるようにし、侵害されたコンテナがクラスタに害を及ぼすのを効果的に防ぐことができます。

もちろん現実の世界では、攻撃者が例えばソースコードリポジトリやビルドツールを侵害することでコンテナイメージにマルウェアを忍び込ませたり、KubernetesのRBACポリシーやセキュリティコンテキストがワークロード間の完全な隔離を保証したりしないことを保証することは不可能です。

ランタイムセキュリティが非常に重要なのはそのためです。ランタイムセキュリティは、Kubernetes環境に忍び寄る脅威に対する最終的な防御層です。パイプラインとクラスターアーキテクチャ内のセキュリティリスクを軽減するためにあらゆる合理的な手段を講じることは可能であり、また講じるべきですが、他の防御を潜り抜けて侵入してくる脅威への警告と制御を支援するランタイムセキュリティも必要です。

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

Kubernetes自体は、ランタイムセキュリティツールの提供は比較的少ないです。Kubernetesが提供する唯一のリソースは監査で、Kuberntes APIへのリソースリクエストを追跡するログを生成できます。

しかし、Kubernetesはこの情報を記録することはできますが、Kubernetesは監査ログを分析したり、不審なアクティビティに対して警告を発したりするようなことは、それ自体では行いません。

そのため、ランタイムの脅威から私たちの環境を保護するためにKubernetes自体に頼るのではなく、外部のランタイムセキュリティツールに頼る必要があります。Kubernetesの場合、これらのツールは、実施ツールと監査ツールの2つの主要なカテゴリに分類されます。

ランタイムセキュリティ強化ツール

強化ツールを使うことで、ランタイム環境内のリソースのアクセス権とパーミッションを制限するポリシーを定義できます。このツールは脅威の顕在化を防ぐことはできませんが、例えば、あるコンテナ内に出現したマルウェアがコンテナ外部のリソースにアクセスできないようにすることで、その影響を最小限に抑えることができます。

Kubernetesの主な強化ツールには次のようなものがあります：

• Seccomp: Seccomp は Linux カーネルレベルのツールで、プロセスを強制的にセキュアな状態 で実行させるために使用できます。seccompを使用してプロセスをセキュアな状態にすると、カーネルはプロセスがexit、sigreturn、既に開いているファイルへの読み書き以外のシステムコールを行わないようにします。
• SELinux: SELinux はカーネルモジュールで、カーネルが実行する幅広いアクセス制御を定義できます。SELinuxを使用すると、コンテナがアクセスできるリソースや実行できるアクションの種類に関する詳細なルールを設定できます。
• AppArmor: AppArmor: AppArmorもカーネルモジュールで、幅広いアクセス制御ルールを定義できます。SELinuxとAppArmorのどちらを使うべきかという議論は、viとemacsのようなものです。どちらかのツールを好む人もいますが、どちらのソリューションでも一般的には同じ結果を得ることができます。

KubernetesのRBACポリシーとセキュリティコンテキストは、コンテナが特権モードで実行されるのを防いだり、カーネルレベルのリソースへのアクセスを禁止したりするのに使用できるため、ある程度、一定レベルの強制制御も提供すると考えることができます。

しかし、一方のRBACポリシーやセキュリティ・コンテキストと、他方のSELinuxやAppArmorのようなツールの違いは、後者がカーネル・レベルでのアクセス制御を強制することです。つまり、Kubernetes自体に何らかの侵害やセキュリティ脆弱性があったとしても、カーネルレベルのエンフォースメントツールによって、侵害されたコンテナが外部リソースにアクセスできないようにすることで、セキュリティ侵害の影響を緩和することができます。

また、SELinux、AppArmor、seccompは、あらゆるタイプのLinuxワークロードのアクセス制御に使用できるため便利です。これらはKubernetesに特化したものではありません。コンテナとVMが混在する環境を管理している場合は、すべてのワークロードを管理するために同じツールを使用できるため、カーネルレベルのアクセス制御フレームワークが便利です。

ランタイムセキュリティのための監査ツール

Kubernetesの監査ツールは、クラスタから収集したデータに基づいて脅威を検出し、対応するのに役立ちます。

繰り返しますが、Kubernetesは監査ログを生成するためのツールを提供しますが、実際にログを解析してくれるわけではありません。そのため、オープンソースの脅威検出エンジンであるFalcoのようなツールを使用することをお勧めします。Falcoでは、Kubernetesの監査ログのようなデータに基づいて、Falcoエンジンが特定の条件の存在を検出した場合にアラートをトリガーするルールを定義することができます。

例えば、Falcoのルールを考えてみましょう：

- rule: Example rule (nginx). This is the human name for the rule.
desc: Detect any listening socket outside our expected one.
condition: evt.type in (accept,listen) and (container.

image!=myregistry/nginx or proc.name!=nginx or k8s.ns.name!=”load-
balancer”)

output: This is where I write the alert message and I provide some
extra information (command=%proc.cmdline connection=%fd.name).
priority: WARNING

このルールでは、以下の条件を満たさないリスニング・ソケットがアラートをトリガーします：

• イメージは myregistry/nginx です。
• リスニングプロセスは nginx です。
• ネームスペースは load-balancer です。

このようなルールを使用すると、貴社の環境で実行されているコンテナが、データを収集したり、不正なリソースにアクセスしようとしている可能性があることを検出できます。また、このようなルールを使用して、未承認のコンテナを検出することもできます。

Falcoは、いくつかの理由から、Kubernetesや同様のプラットフォーム向けの事実上の監査ツールとなっています。オープンソースであることに加え、FalcoはKubernetesだけでなく、あらゆるタイプのクラウドネイティブ環境で動作する能力を提供します。

同時に、Cloud Native Security Hubのリポジトリは、さまざまなタイプのワークロードに合わせて事前に設定された数十のFalcoルールを提供するため、多数の監査ルールを手作業で記述することなく、Falcoを簡単に迅速に設定することができます。

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

Kubernetesのランタイムセキュリティの脅威に対処するために必要なステップの1つに、強制ツールと監査ツールの導入がありますが、これらのツールを単にセットアップするだけではありません。また、下記について確認する必要があります：

• 継続的なイメージスキャンの実行： イメージスキャンは、それ自体はセキュリティのランタイムオペレーションではありませんが（パイプラインセキュリティの範囲に入ります）、イメージスキャンは、マルウェアがランタイム環境に到達するのを防ぐために重要です。
• Kubernetesポリシーファイルのスキャン： KubernetesのRBACファイル、デプロイメント、その他のリソースをスキャンして、ランタイムの侵害を可能にしたり、悪化させたりする可能性のある誤った設定を検出することで、ランタイムのセキュリティ問題を防ぐこともできます。
• 外部ポリシーファイルのスキャン: SELinux、AppArmor、またはその他のフレームワーク用に作成したポリシーファイルやプロファイルもスキャンする必要があります。これらのファイル内の見落としは、ランタイムの防御を弱める可能性があります。
• dev/test を忘れないでください： ランタイム・セキュリティ防御を適用する場合、何よりもまず本番環境に焦点を当てがちです。結局のところ、脅威が最も大きな影響を与えがちなのはそこだからです。しかし、開発／テスト環境のセキュリティも忘れないでください。開発／テスト環境でランタイムの脅威をキャッチすることは、本番環境に脅威が到達するのを防ぐ素晴らしい方法です。さらに、開発／テスト環境であっても、ランタイム・セキュリティの問題は、例えば、攻撃者が開発／テスト・リソース内から秘密データにアクセスすることができた場合、大きな結果をもたらす可能性があります。
• インシデントの修復計画を立てること： 情報漏えいが発生してから対応策を練るのではいけません。さまざまなタイプの実行時セキュリティ事象に対応するためのプレイブックを作成します。例えば、特権昇格攻撃が発生した場合はどうしますか。1つのノードが侵害されたが、他のKubernetesノードは侵害されていない場合はどうしますか？このような問題を事前に考えておくことで、実際の脅威により迅速に対応することができます。

ランタイムセキュリティは、アプリケーション開発パイプラインとKubernetesアーキテクチャの中に構築した他の防御をかいくぐって、クラスタと脅威の間に立ちはだかる唯一のものです。しかし、ランタイム環境を継続的に監査し、エンフォースメントツールを使用してランタイムリソースを互いにセグメント化することで、ランタイムの脅威の潜在的な影響を最小限に抑えることができます。