Kubernetes のセキュリティに関するよくある質問
コンテナの普及に伴い、アプリケーションの構築とリリースをより効率的かつ迅速に行うため、コンテナのオーケストレーションに Kubernetes を採用する企業の数が過去最多を記録しています。
Kubernetes を使用することで、必要なものをすべて使用して、あらゆる環境でアプリケーションを安定して実行できるようになります。Google によって開発され、現在はCloud Native Computing Foundationが管理している Kubernetes は、コンテナ化されたアプリケーションの展開と管理を大規模に自動化し、迅速かつ自動化されたソフトウェアのデプロイに伴う問題や障害を解消します。
これらが一般的になるにつれ、コンテナや Kubernetes などのコンテナオーケストレーションツールも、攻撃対象としてハッカーに狙われやすくなります。Kubernetes は企業内で広く普及しつつありますが、発生する可能性の高い、主なセキュリティ問題についてしっかり把握しておく必要があります。この記事では、Kubernetes に関連してよく聞かれるセキュリティ関連の質問をご紹介します。
コンテナは root として実行可能か
コンテナが root として実行されている場合、コンテナへの侵入で防御を回避した攻撃者は、ネットワーク上で無制限のネットワークアクセスを得ることができる可能性があります。コンテナに侵入した後、攻撃者はネットワークのスキャン、ファイルシステムの探索、パッケージのダウンロード、root ユーザー専用のコマンドの実行などを自由に行うことができます。このような「コンテナブレイクアウト」のシナリオでは、コンテナの隔離メカニズムがバイパスされ、ホスト上で追加権限が取得された場合、ハッカーの制御下でコンテナが root として実行されることさえあります。
以下の防御メカニズムをデプロイして、クラスター内でコンテナが root として実行されるのを阻止することで、リスクを軽減することが可能です。
PodSecurityPolicy は、API アドミッション・コントローラー・レイヤーで、root としての実行を要求するコンテナやポッドを明示的に拒否することができるクラスターレベルのリソースです。
Open Policy Agent は、より柔軟な制限の適用を可能にするポリシーコントロールツールです。
コンテナは機密性の高いボリュームやディレクトリをマウント可能か
コンテナにマウントされているボリュームやディレクトリを「hostPath」設定で確認できることが重要です。Kubernetes クラスター内でコンテナをマウントする際には、さまざまな影響があることにご注意ください。ホストマシン自体から特定のボリュームとディレクトリをマウントすることができます。ログなど日常的なタスクでコンテナをマウントすることは問題ありませんが、機密データに対してこのレベルのアクセス権限を付与した場合、セキュリティ上の懸念が生じる可能性があります。
ファイルシステムの設定が Read または Read/Write に設定されているか
デフォルト設定では Read が優先されます。ルートファイルシステムや危険なファイルが Read/Write 形式でマウントされている場合、攻撃者によって CVE-2016-9962 として知られるコンテナエスケープの脆弱性が悪用される可能性があります。完全なコンテナエスケープが行われた場合、攻撃者は制限された環境からコンテナを削除し、基盤となるホストサーバーを悪用することができます。
ポッドは特権モードで実行できるか
コンテナが特権モードで実行されると、基盤となるホストで利用可能なほとんどのシステム機能へのアクセスが付与されるため、コンテナの攻撃対象領域が大幅に拡大します。そのため、特権モードの使用を完全に禁止することをご検討ください。追加のシステムコールが必要な場合は、PodSpec の SecurityContext で明示的に定義できます。
どのようなポリシーが誰のために実施されているか
時間をかけてルールを監査し、想定通りに機能することを確認します。DevOps ツールを使用することで、セキュリティチームはクラスター内で実行されるワークロードをより厳密にポリシーコントロールすることができます。しかしサードパーティのツールの使用によって、既存ポリシーが誤って設定されたり、別のポリシーで上書きされる可能性もあります。このため、定期的に手動でポリシーチェックを行うことが重要です。
認証はどのように処理されているか
Kubernetes は複数の認証メカニズムをサポートしています。認証のベストプラクティスを導入してクラスターへのアクセスを保護する必要があります。万能のソリューションはありませんが、多要素認証 (MFA) や認証情報を失効させる機能、認証情報の共有を一切行わないなど、効果的な認証ポリシーを導入するようにしてください。
Kubernetes では権限がどのように扱われるか
Kubernetes ではロールベースのアクセスコントロール (RBAC) がリソース保護の中核をなしています。「最小権限の原則」 (PoLP) とは、意図された機能を実行するために必要な最小限のアクセス権限のみを各モジュール (つまり各ユーザー、プロセス、デバイス、プログラム) に与えることを意味します。PoLP に基づいてアクセス権限を付与するシステムを構築することで、攻撃の影響範囲を制限できます。rakkess、rback、krane、kubectl-who-can など、セキュリティチームが RBAC を適切に監査し、実行するのに役立つツールを検討しましょう。
Kubernetes Secret はどのように保存、取得、ローテーション、失効されるのか
お客様の環境の完全性を保つために、Secret は細心の注意を払って取り扱う必要があります。Kubernetes Secret API や etcd などを使って Secret を保存することができます。
コンテナイメージはどこから取得されるか
コンテナイメージは、アプリケーションとその基盤にあるすべてのファイルとソフトウェアの依存関係をカプセル化したバイナリデータセットです。コンテナイメージは動的で、通常Docker Hubや公開されているレジストリなどのソースから取得しますが、これらのソースが悪意のあるイメージをホストしている可能性もあります。クラスターを設定する際は、イメージレジストリが信頼でき、安全で完全性がチェックされていることを確認してください。イメージスキャン技術を使用し、最小限のベースイメージを構築することで、コンテナの攻撃対象領域を最小限に抑えることができます。
どのようにしてネットワークセキュリティが確保されているか
ネットワーク・セキュリティ・ポリシーによって、ポッド間の通信に制限を設定することが可能です。クラスター内のネットワーク通信、egress および ingress はできる限り細かく設定する必要があります。接続ソースを制限することで、ポッドを保護できます。ネットワーク通信の監査には、Kubernetes Network Policies やサービスメッシュ (Istio など) の利用をご検討ください。
モニタリングによってホストの堅牢性が確保されているか
Kubernetes は通常、仮想マシンや物理的なハードウェアに依存してワークロードを実行しています。そのため、これらのホストマシンの堅牢性を適切に確保する必要があります。不要なポートをすべて閉じ、システムにパッチを適用してネットワークを確実にロックダウンしてください。システムの堅牢化については、該当する CIS ベンチマークに従うことをご検討ください。
Kubernetes Auditing とは何か
Kubernetes Auditing は、クラスター内で発生したイベントやアクティビティについて、セキュリティ関連のログを提供します。ログは、セキュリティチームによる保存と分析のため、別のログ集計システムに送信する必要があります。
ingress/ロードバランシングはどう機能しているか
どのような外部 IP が利用可能ですか？クラスターへの外部アクセスを管理する API オブジェクトの ingress は、トラフィックの負荷分散に役立ちます。オフになっている場合、Kubernetes API は外部のロードバランサーやパブリック IP を自動的に作成することができます。ワークロードが外部の攻撃者や好奇心旺盛なユーザーにさらされることがないようにしてください。
アプリケーションにサーバー・サイド・リクエスト・フォージェリ (SSRF) やリモートコード実行 (RCE) のバグがある場合はどうすればよいか
両方のシナリオとインシデントレスポンスを詳細に確認する演習を実施し、堅牢な防御対策が施されていることを確認します。SSRF または RCE 攻撃が成功した場合の影響範囲を制限するためのセキュリティ対策を講じます。
Kubernetes 環境に対する脅威に備えるために他に何ができるか
最も一般的な「起こりうる」セキュリティシナリオに対する脅威モデルを構築してください。クラスターの誤動作、インサイダー脅威、設定ミス、攻撃シナリオが発生した場合に、チームがどのように対応するかをマッピングします。脅威モデルの作成は、公式でも非公式でも構いません。まず手始めに、Marco Lancini 氏のブログ記事「The Current State of Kubernetes Threat Modelling (Kubernetes 脅威モデリングの現状)」をお勧めします。
さらに、すべてのサードパーティコンポーネントが更新されていることを確認します。使用されていない統合機能は削除します。ダッシュボード、ライブラリ、およびプラグインはすべて、Kubernetes エコシステムにおけるリスク要因です。
Kubernetes はエキサイティングな新しいエコシステムを提供しますが、すべてのツール、システムおよび環境同様、安全性が確保されていてこそ有効に活用できます。
