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

Kubernetesのランタイムセキュリティは、コンテナが実行されている際に、コンテナ（またはポッド）をアクティブな脅威から保護するものです。

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

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

このようなランタイムの脅威が現実のものとなることは、理想的な世界では決してありません。なぜなら、脅威が本番環境に侵入することが決してないように、アプリケーションのパイプラインとクラスターを保護するからです。また、厳格なアクセス制御を使用して、各ワークロードが適切に分離されていることを確認し、侵害されたコンテナがクラスタに害を及ぼすことを効果的に防止します。

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

だからこそ、ランタイムセキュリティが重要になるのです。これは、Kubernetes環境に忍び込む可能性のある脅威に対する最後の防御層です。パイプラインやクラスタアーキテクチャ内のセキュリティリスクを軽減するために、あらゆる合理的な対策を講じることができ、また講じるべきですが、他の防御をすり抜ける脅威を検知し、制御するためには、ランタイムセキュリティも必要です。

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

Kubernetes自体は、ランタイムセキュリティツールとしては比較的機能が限られています。唯一提供されている実質的なリソースは監査機能であり、Kuberntes APIへのリソースリクエストを追跡するログを生成することができます。

しかし、Kubernetesはこれらの情報を記録することはできても、監査ログを分析したり、疑わしい可能性のあるアクティビティを警告したりするようなことは自動的には行いません。

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

ランタイムセキュリティの強制実行ツール

強制実行ツールを使用すると、実行環境内のリソースへのアクセス権と許可を制限するポリシーを定義することができます。このツールは脅威の発生を防ぐことはできませんが、たとえば、1つのコンテナ内に現れたマルウェアがコンテナ外のリソースにアクセスできないようにすることで、その影響を最小限に抑えることができます。

エンドツーエンドの検知によりクラウドを保護

さらに詳しく

Kubernetesの主な強制実行ツールには、次のものが含まれます。

• Seccomp: Seccompは、プロセスを安全な状態で実行させるために使用できるLinuxカーネルレベルのツールです。seccompを使用してプロセスを安全な状態にすると、カーネルはプロセスがexit、sigreturn、およびすでにオープンされているファイルの読み書き以外のシステムコールを実行できないようにします。
• SELinux: SELinuxは、カーネルが強制する広範なアクセス制御を定義できるカーネルモジュールです。SELinuxを使用すると、コンテナがアクセスできるリソースや実行できるアクションの種類について、きめ細かいルールを設定できます。
• AppArmor：AppArmorもまた、広範なアクセス制御ルールの定義を可能にするカーネルモジュールです。SELinuxと非常に類似した点が多く、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だけでなく、あらゆるタイプのクラウドネイティブ環境で動作する機能を提供しています。

同時に、さまざまなタイプのワークロードに合わせた多数の事前設定済みのFalcoルールを提供するCloud Native Security Hubリポジトリにより、監査ルールを大量に手作業で作成することなく、Falcoを簡単に素早く設定することができます。

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

Kubernetesのランタイムセキュリティの脅威に対処するために必要なステップの1つとして、強制および監査ツールの展開が挙げられますが、これらのツールの設定だけでは十分ではありません。さらに、以下のことを確実に行う必要があります。

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

ランタイムセキュリティは、アプリケーション開発パイプラインやKubernetesアーキテクチャ内に構築した他の防御策をくぐり抜けてしまった脅威から、クラスタを守る唯一の手段です。しかし、ランタイム環境を継続的に監査し、ランタイムリソースを互いに分離する強制ツールを使用することで、ランタイムの脅威による潜在的な影響を最小限に抑えることができます。