ツールを使ってKubernetesランタイムセキュリティ脅威を防ぐには？
SHARE:
ランタイムセキュリティの重要性は広く知られています。しかし、Kubernetesのセキュリティ戦略の一環として、ランタイムセキュリティを見落としたり、リソース不足に陥ったりした結果、しっかりと対策しきれないケースは珍しくありません。
その理由は Kubernetesが非常に複雑なシステムなことにあります。権限へのアクセスやワークロードの分離を支援するために非常に多くの種類のネイティブツールが存在していることから、とにかく把握すべき事項が多いです。管理者のなかには、クラスタ自体のセキュリティ確保に没頭するあまり、Kubernetesのランタイムセキュリティのことを忘れてしまう方もいるかもしれません。
この記事では、改めてKubernetesのランタイムセキュリティがなぜ重要なのかを確認したうえで、脅威からKubernetesを保護するためにどのようなツールが利用可能かを解説します。
関 連 記 事
| Kubernetesとは？ | Kubernetesセキュリティ の基礎 | Kubernetesアーキテクチャの 設計方法 |
| AWSのEKS （Elastic Kubernetes Service） | Kubernetesの クラスターとは？ | Kubernetes のノードとは？ |
| KubernetesのPodとは？ | KubernetesのHelmとは？ | クラウドセキュリティと ランタイムインサイト |
ランタイムセキュリティの基礎知識
Kubernetesにおけるランタイムセキュリティとは、コンテナ（またはポッド）をコンテナ実行後のアクティブな脅威から保護することです。導入により、コンテナがデプロイされた後に出現しうるさまざまな脅威からワークロードを守ることができます。
脅威としては、例えば以下があります。
- コンテナイメージ内に隠されたマルウェアの起動。
- コンテナが、コンテナランタイム、Kubernetes、またはホストOSのセキュリティバグを悪用して、アクセスできないはずのリソース（ストレージボリュームや外部バイナリなど）にアクセスする特権昇格攻撃。
- アクセス制御ポリシーのギャップやKubernetesのバグを悪用した攻撃者による不正なコンテナのデプロイ
- 実行中のコンテナが読み取ることができないはずの秘密情報やその他の機密情報への不正アクセス。ただし、不適切なアクセス制御設定や、特権の昇格を可能にするセキュリティ脆弱性のために、コンテナがアクセスできてしまう場合
仮に理想的な対策を実行できれば、このような脅威が発生することはありません。なぜなら、アプリケーション・パイプラインとクラスタが、実行環境に脅威が侵入することがないように保護されているからです。厳格なアクセス制御を使用して各ワークロードが適切に隔離されるようにすれば、侵害されたコンテナがクラスタに害を及ぼすのを効果的に防ぐことができます。
もちろん現実では、なかなか完璧な対策は難しいです。例えば、攻撃者がソースコードリポジトリやビルドツールを侵害することでコンテナイメージにマルウェアを忍び込ませることもあるでしょう。KubernetesのRBACポリシーやセキュリティコンテキストがワークロード間の完全な隔離は、現実的には不可能です。
ランタイムセキュリティが非常に重要な理由はそこにあります。いうなれば、Kubernetes環境に忍び寄る脅威に対する最終防壁です。パイプラインとクラスターアーキテクチャ内のセキュリティリスクを軽減するためにあらゆる合理的な手段を講じることは可能ですが、全てを防げるわけではありません。他の防御を潜り抜けて侵入してくる脅威への警告と制御を支援するランタイムセキュリティの併用も必要です。
Kubernetesランタイムセキュリティツール
Kubernetes自体は、ランタイムセキュリティツールの提供は比較的少ないです。
唯一のリソースは監査で、Kuberntes APIへのリソースリクエストを追跡するログを生成できます。しかし、情報を記録することはできますが、監査ログを分析したり、不審なアクティビティに対して警告を発したりまではできません。
そのため、ランタイムの脅威から私たちの環境を保護するためには、外部のランタイムセキュリティツールに頼る必要があります。大きく実施ツールと監査ツールの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のランタイムセキュリティの脅威に対処するために必要なステップの1つに、強制ツールと監査ツールの導入がありますが、これらのツールを単にセットアップするだけではありません。また、下記について確認する必要があります。
- 継続的なイメージスキャンの実行： イメージスキャンは、それ自体はセキュリティのランタイムオペレーションではありませんが（パイプラインセキュリティの範囲に入ります）、イメージスキャンは、マルウェアがランタイム環境に到達するのを防ぐために重要です。
- Kubernetesポリシーファイルのスキャン： KubernetesのRBACファイル、デプロイメント、その他のリソースをスキャンして、ランタイムの侵害を可能にしたり、悪化させたりする可能性のある誤った設定を検出することで、ランタイムのセキュリティ問題を防ぐこともできます。
- 外部ポリシーファイルのスキャン: SELinux、AppArmor、またはその他のフレームワーク用に作成したポリシーファイルやプロファイルもスキャンする必要があります。これらのファイル内の見落としは、ランタイムの防御を弱める可能性があります。
- dev/test を忘れないでください： ランタイム・セキュリティ防御を適用する場合、何よりもまず本番環境に焦点を当てがちです。結局のところ、脅威が最も大きな影響を与えがちなのはそこだからです。しかし、開発／テスト環境のセキュリティも忘れないでください。開発／テスト環境でランタイムの脅威をキャッチすることは、本番環境に脅威が到達するのを防ぐ素晴らしい方法です。さらに、開発／テスト環境であっても、ランタイム・セキュリティの問題は、例えば、攻撃者が開発／テスト・リソース内から秘密データにアクセスすることができた場合、大きな結果をもたらす可能性があります。
- インシデントの修復計画を立てること： 情報漏えいが発生してから対応策を練るのではいけません。さまざまなタイプの実行時セキュリティ事象に対応するためのプレイブックを作成します。例えば、特権昇格攻撃が発生した場合はどうしますか。1つのノードが侵害されたが、他のKubernetesノードは侵害されていない場合はどうしますか？このような問題を事前に考えておくことで、実際の脅威により迅速に対応することができます。
まとめ
ランタイムセキュリティは、アプリケーション開発パイプラインとKubernetesアーキテクチャの中に構築した他の防御をかいくぐって攻撃してくる脅威から、クラスタを保護できる唯一の手段です。
ツールを活用してランタイム環境を継続的に監査し、エンフォースメントツールを使用してランタイムリソースを互いにセグメント化することで、潜在的なリスクを最小限に抑えることができます。