クラウド環境
Kubernetesセキュリティの3本の柱であるイメージスキャン、アドミッションコントローラ、ランタイムセキュリティについて理解する
K8sとも呼ばれるKubernetesは、非常に複雑なオープンソースプラットフォームであり、そのセキュリティには細心の注意を払う必要があります。これまでのセキュリティ強化の取り組みにもかかわらず、Kubernetesは依然としてデフォルトで安全とは言えず、クラスタの保護にさまざまなセキュリティツールを必要とします。
K8sとも呼ばれるKubernetesは、非常に複雑なオープンソースプラットフォームであり、そのセキュリティには細心の注意を払う必要があります。これまでのセキュリティ強化の取り組みにもかかわらず、Kubernetesは依然としてデフォルトで安全とは言えず、クラスタの保護にさまざまなセキュリティツールを必要とします。K8sセキュリティツールの3本の柱であるイメージスキャン、アドミッションコントローラ、ランタイムセキュリティは、クラウドネイティブセキュリティシステムの4つのCによってカバーされています。今回の記事では、これらのツールの詳細、および使用するタイミングについて説明するとともに、推奨されるオープンソースツールをいくつか紹介します。
市場には他にも多くのオプションがありますが、必要なのはこれらのツールのみであり、業界の観点から最も重要であると考えられています。
イメージスキャン
Kubernetesクラスタでは、K8sワークロードの最小単位であるポッドをデプロイします。各ポッドはストレージとネットワークリソースを共有でき、ポッドにはコンテナを1つ以上含めることができます。クラスタでコンテナを実行する前に、コンテナが信頼できるものであり、コンテナに重大なセキュリティの問題がないことを確認しますが、このプロセスを「イメージスキャン」または「コンテナスキャン」と呼びます。
イメージスキャンでは、特定のコンテナイメージを分析してセキュリティの問題を検出します。これらの問題には、設定ミス、脆弱性、場合によってはマルウェアなどがあります。イメージスキャンプロセスにより、各コンテナイメージレイヤ（つまり、コンテナは一連のレイヤから構成されています）を分析し、各レイヤにインストールまたは設定されているソフトウェアに既知のセキュリティの問題があるかどうかを確認します。このプロセスでは通常、National Vulnerability Database（NVD）、Open Source Vulnerability（OSV）データベース、GitHub Security Advisory（GHSA）データベースなどの公開脆弱性情報データベースが利用されますが、一部の商用ツールでは、独自の脆弱性情報データベースが使用されることもあります。
以下に、Docker HubにあるApache httpd Dockerイメージのイメージレイヤの例を示します。
イメージスキャンツールは、これらのイメージレイヤを分析することで、インストールされているアプリケーションとそのバージョンを特定し、これらのアプリケーションに関連する脆弱性を調査します。一部のコンテナイメージには、ベースイメージと呼ばれる別のコンテナイメージに基づいて作成されるものもあり、これは、その新しいコンテナイメージが、ベースイメージに含まれる脆弱性を継承することを意味します。ベースイメージを変更すれば、最終的なイメージで検出される脆弱性を大幅に削減できる可能性があるため、この点は重要です。docker scanコマンドなどの一部のツールでは、最も安全なベースイメージが提案されます。
トレンドマイクロの最新のLinux脅威レポートにおいて、Docker Hubで最も人気のあるトップ15の公式Dockerイメージを分析したところ、そのすべてに少なくとも1つの重大な脆弱性があることがわかりました。コンテナを一から作成したり、Alpine Linuxなどの小さなイメージを使用したりするのでない限り、脆弱性ポリシーを作成してコンテナイメージに適用することを検討してください。この状況に対するもう1つのソリューションとして、Distroless技術を使用する方法もあります。
Clair
Clairは、最初のオープンソースイメージスキャナの1つであり、現在最も人気のあるセキュリティ監視ツールの1つです。Goで開発されており、IBMのRed Hat事業部に属するQuay組織によって保守されています。Clairを使用することで、コンテナのコンテンツ情報をレイヤごとに抽出し、潜在的なセキュリティの脆弱性を特定することができます。コンテナイメージをスキャンするためにClairを実行する方法はいくつかあります。GitHubでリリースされている最新バージョンをダウンロードしてDockerイメージを実行することもできれば、GitHubリポジトリとDocker Composeを使用して、テスト目的でローカル開発環境をセットアップすることもできます。
Docker Scout
イメージスキャンのもう1つのオプションとして、新しいDocker Scoutコマンドがあります。これまでDocker Scanとして知られていたDocker Scoutは、現在も開発の初期アクセス段階にあります。Docker CLIを使用する場合は、Docker Scoutコマンドを使用して、Dockerイメージの脆弱性をスキャンおよび評価できます。
2020年に追加され、2023年に名称変更されたDocker Scoutを使用すれば、いつでも簡単にコンテナイメージをスキャンできます。
他の脆弱性スキャンツール同様、コンテナイメージスキャンソリューションはコンテナイメージをスキャンし、レイヤ、パッケージ、インストールされているバージョンに関するデータを収集して、脆弱性情報データベースと比較します。したがって、この方法の有効性は、脆弱性情報データベースの品質、編成、および保守にかかっています。通常、National Vulnerability Database（NVD）などの公開脆弱性情報データベースに頼るだけでは不十分です。
アドミッションコントローラ
アドミッションコントローラは、クラスタへのK8sオブジェクトのアドミッション（リクエストを受け入れるかどうか）を管理します。認証および認可フェーズの後、kube-apiserverによって呼び出されます。
アドミッションコントローラには、次の3つのタイプがあります。
- 変更 – リクエスト内のオブジェクトを変更できます。
- 検証 – 現在のオブジェクトの構造と情報の検証のみを行います。
- 両方 - 変更機能と検証機能の両方を実行します。
Kubernetesにはすぐに使用できる複数のアドミッションコントローラがあり、それをクラスタ内で有効にできます。ネイティブコントローラの完全なリストについては、K8sのドキュメントを参照してください。
しかし、クラスタ内でこれらのアドミッションコントローラを有効にする意味は何でしょうか。これらの設定によって、クラスタの動作が遅くなったり複雑になったりしないのでしょうか。
Docker Hubで入手可能なコンテナイメージを実行するには、クラスタでの実行を許可する前に、そのイメージの脆弱性が十分にスキャンされていることを確認する必要があります。このタスクを達成する例として、OPA/GatekeeperとKyvernoという2つの外部アドミッションコントローラを使用する方法があります。
Open Policy Agent（OPA）とGatekeeper
Open Policy Agent（OPA）は、よく知られたクラウドネイティブのポリシーエージェントで、K8sのみならず幅広いアプリケーションに対応しています。継続的インテグレーション（CI）/継続的デプロイ/デリバリ（CD）パイプライン、APIゲートウェイなどのポリシーを作成して、アプリケーションを予期したとおりに動作させたり、デプロイ前にすべてのコンテナイメージをスキャンするなどのコンプライアンス要件を適用したりすることができます。
この記事では、Gatekeeperと呼ばれる、K8s用のOPAのより特殊なバージョンに焦点を当てます。Gatekeeperは、Kubernetesのアドミッションコントロールに、OPAのRegoエンジンとネイティブK8sリソースを利用します。
Gatekeeperのインストール
Gatekeeperをクラスタにインストールする方法はいくつかあります。最も簡単な方法の1つは、事前に構築されたイメージを使用するかHelm経由でリリースをデプロイすることです。事前に構築されたイメージを使用してリリース済みのバージョンをデプロイするには、以下の「kubectl」コマンドを実行します。これにより、次のK8s APIオブジェクトが作成されます。
$ kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/release-3.7/deploy/gatekeeper.yaml
数秒後、すべてがインストールされ、すべてのオブジェクトが作成されてスムーズに実行されるはずです。上の図に示しているように、Gatekeeperはgatekeeper-systemという名前空間を作成するので、次に示す「kubectl get all」コマンドを使用することでこの名前空間をクエリできます。
$ kubectl get all -n gatekeeper-system
Gatekeeperを予期したとおりに動作させ、クラスタにポリシーを適用するにはどうすればよいでしょうか。OPAとGatekeeperの使用方法やテスト環境への適用方法について詳しくは、このドキュメントに記載している例を参照してください。
制約と制約テンプレートがどのように連携するのかを理解することは、ポリシーを作成したり、コミュニティによって提供され、Gatekeeperライブラリリポジトリで利用可能な既存のポリシーを活用したりするのに役立ちます。権限昇格を許可するポリシーの例について、こちらのWebサイトを参照してください。
Kyverno
Kyvernoは、K8sクラスタのアドミッションコントローラとして機能するもう1つのツールです。「Kyverno」という名前は、「統制」を意味するギリシャ語に由来しています。Kyvernoの興味深い事実として、（OPAのRegoのように）新しい言語を学習する必要がありません。他のアドミッションコントローラ同様、KyvernoはK8s APIサーバに送信されるリクエストを変更または検証します。
Kyvernoのインストール
Kyvernoは、Helm経由またはYAMLマニフェストを使用して簡単にインストールできます。最新バージョンのKyverno（バージョン1.6～1.10）は、バージョン1.16以上のKubernetesクラスタのみに対応することに注意してください。そのため、HelmまたはYAMLをインストールする前に、クラスタが最新であることを確認してください。
以下は、Helmチャートを使用してKyverno 1.6.2をインストールした後のクラスタの例を示しています。
$ kubectl get all –n kyverno
次の図は、デフォルトのインストールを使用したオブジェクトのアーキテクチャを示しています。
OPAやGatekeeperと同様に、Kyvernoはアドミッションコントローラを作成して、ポリシーとルールを適用する際にkube-apiserverからのリクエストの変更や検証を処理します。これらのポリシーとルールに基づき、Kyvernoは検証がenforceに設定されている場合はリクエストをブロックし、auditに設定されている場合はリクエストを許可して問題をログに記録します。
Kyvernoとそのポリシーをインストールすると、「kube-system」と「kyverno」名前空間を除く、リソースを含むクラスタ上のすべてのKubernetes名前空間に対して「policy reports」という名前のオブジェクトが作成されることがわかります。次のコマンドを使用すると、「kyverno」によって生成されたすべてのポリシーレポートをリストできます。
$ kubectl get policyreport –A
Pod Security Policy x Pod Security Admission
アドミッションコントローラに言及する場合、非推奨となったPod Security Policy（PSP）と新たなPod Security Admissionについて取り上げることが重要です。PSPはアドミッションコントローラの古いバージョンとして機能していたもので、ポッドに対してセキュリティコンテキストとも呼ばれる一連の権限とアクセス制御設定を指定できました。PSPで適用できるセキュリティコンテキストの例をいくつか紹介します。
- AllowPrivilegeEscalation – コンテナが親プロセスよりも多くの権限を取得できるかどうかを確認します。ベストプラクティスとして、これは「False」に設定することをお勧めします。
- RunAsNonRoot – コンテナを非rootユーザとして実行させます。この設定は「True」にすべきです。
- ReadOnlyRootFileSystem – コンテナのルートファイルシステムを読み取り専用モードでマウントします。この設定は「True」にすべきです。
セキュリティコンテキスト設定の完全なリストについては、K8sの公式のドキュメントを参照してください。
PSPはKubernetes 1.21から非推奨となり、バージョン1.25で完全に対応がなくなり、2023年10月にサポート終了（EOL）となりました。まだこれらのバージョンを使用している場合は、クラスタを最新のものにアップグレードすることを検討してください。PSPが非推奨となった背景については、公式のK8sに関するブログ記事を参照してください。
PSPの後継機能である新たなPod Security Admissionは、現在ベータ版として提供されており、Kubernetes 1.23以降デフォルトで有効になっています。この新たな組み込みのアドミッションコントローラでは、次の3つのセキュリティレベルに基づいてポッドを分類できます。
- privileged – 無制限のアクセスが提供され、権限昇格が可能です。
- baseline – 最小限の制限が提供される、ポッドのデフォルト設定です。
- restricted – 厳しい制限が提供され、ポッド強化のベストプラクティスに従います。
各名前空間でポッドに適用するアドミッションコントロールモードを定義することもできます。次のモードがあります。
- enforce – 違反によりポッドがクラスタに参加することが拒否されます。
- audit – 違反は監査ログに記録されますが、ポッドはクラスタに参加できます。
- warn – 違反によりユーザに警告が表示されますが、これらのエントリはログに記録されません。
ランタイムセキュリティ
コンテナイメージをスキャンしており、クラスタへのアドミッションを制御していると仮定した場合、Kubernetesセキュリティを支える最後の柱は、実行中のコンテナが実行後に変更されないようにすることです。これは、クラスタで実行しているものが、コンテナイメージのコンテンツと一致していることを確認することを意味します。ここで、ランタイムセキュリティが登場します。
アドミッションコントローラがナイトクラブの用心棒のようなものとすると、ランタイムセキュリティはサッカーの試合における審判です。サッカーの試合では、審判はフィールド内で何が起こっているかを確認し、各プレーヤー（ポッドまたはコンテナ）が何をしているかを監視します。試合中に審判がイエローカードやレッドカードを出すのと同様に、ランタイムセキュリティは不審な動きを検知して警告することができます。こうした動きには、不審なアクティビティのブロックやクラスタからの完全な削除などがあります。
この段階で使用されるメカニズムの1つは、「ドリフト検出」と呼ばれています。このメカニズムは、元のコンテナイメージを確認し、それを実行中のコンテナの実際の状態と比較することで機能します。実行中のプロセスやインストールされているパッケージなどに違いがある場合、そこにズレが生じ、それがコンテナが実行後に変更された証拠になります。技術的にこのような状況は発生しないはずですが、場合によっては起こることがあります。
イミュータブルインフラストラクチャの原則に従えば、コンテナが実行後に変更されることはないはずです。この原則では、一般的なサーバのように、コンテナにパッチやアップデートが適用されることはありません。パッチやアップデートが必要な場合は、常に、古いコンテナイメージを新しいコンテナイメージで置き換える必要があります。このプロセスにより、イメージのコンテンツが本番環境で実行されているものと常に一致するようになります。
しかし、攻撃者がコンテナ環境内のアプリケーションを侵害し、悪意のあるパッケージや暗号通貨マイナーなどの新しいソフトウェアをインストールしたらどうなるでしょうか。こうした実行時の不審な変更や悪意のある変更を検知することが、ランタイムセキュリティの主要な目的の1つです。これを実現する最先端技術の1つに、eBPFがあります。
eBPF
これまでBPFの拡張仕様として知られていたeBPF（extended Berkeley Packet Filter）は、多くのコンテナセキュリティソリューションで使用されている基盤テクノロジであり、サンドボックス化または分離されたプログラムをOSのカーネル内で実行することができます。ebpf.ioによると、eBPFを使用することで、カーネルのソースコードを変更したりカーネルモジュールをロードしたりすることなく、カーネルの機能を安全かつ効率的に拡張できます。トレンドマイクロは最近、攻撃者がeBPFを悪意のある目的で利用する手法についてレポートを公開しました。
Falco
Falcoは、セキュリティと可観測性を実践するための主要なオープンソースツールの1つです。カスタマイズ可能で柔軟なルールエンジンを備えたCloud Native Computing Foundation（CNCF）プロジェクトであり、システム上の不審な動きを監視するためのルールとアラートを作成できます。コンテナの侵入検知システム（IDS）として認識されています。
独自のルールを作成するための専門知識やリソースがなくても、保守担当者が提供するデフォルトのルールセットを使用するか、https://securityhub.dev/で入手可能な、コミュニティによって開発された特定のルールを使用すれば、Falcoを利用することができます。
Falcoのドキュメントによると、Falcoは現在、デフォルトのルールセットに基づいて次のような確認を行っています。
- 特権コンテナを使用した権限昇格
- setnsなどのツールを使用した名前空間の変更
- /etc、/usr/bin、/usr/sbinなどのよく知られたディレクトリに対する読み取り/書き込み
- シンボリックリンクの作成
- 所有権やモードの変更
- 予期しないネットワーク接続やソケットの変更
- execveを使用して生成されたプロセス
- sh、bash、csh、zshなどのシェルバイナリの実行
- ssh、scp、sftpなどのSSHバイナリの実行
- LinuxのCoreutilsの実行可能ファイルの変更
- ログインバイナリの変更
- shadowconfig、pwck、chpasswd、getpasswd、change、useraddなど、shadow-utilsやpasswdの実行可能ファイルの変更
まとめ
今回の記事では、「K8sセキュリティの3本の柱であるイメージスキャン、アドミッションコントローラ、ランタイムセキュリティ」と呼ばれる、Kubernetesセキュリティツールセットの3つのコアコンポーネントについて紹介し、その機能を確認するとともに、オープンソースツールの例をいくつか挙げました。DevSecOpsの「セキュリティシフトレフト」戦略のように、コンテナのセキュリティの問題を早期に検知できれば、それだけ修正は容易かつ迅速になります。単一のツールではクラスタを攻撃から保護できないことを理解することが重要であり、そのため、Kubernetesに関するセキュリティについて総体的な視点を持つことが不可欠です。
多層防御戦略を常に念頭に置き、最小特権の原則を適用してください。こうした戦略は最終的に、攻撃が発生した場合の影響を最小限に抑えるのに役立ちます。
参考記事
Understanding the Kubernetes Security Triad: Image Scanning, Admission Controllers, and Runtime Security
By: Magno Logan