Kubernetes セキュリティの基礎: 基礎とベストプラクティス

Kubernetes のセキュリティ確保は、一見すると難しい作業に思えるかもしれません。Kubernetes はさまざまなコンポーネントで構成される非常に複雑なシステムであり、セキュリティモジュールを有効にしたり、セキュリティツールをインストールしたりするだけでは保護できません。

Kubernetes のセキュリティを確保するには、Kubernetes クラスター内のさまざまなレイヤやサービスに影響を及ぼす可能性のあるセキュリティリスクのタイプごとに対処する必要があります。たとえば、チームは Kubernetes のノード、ネットワーク、ポッド、データなどを保護する方法を理解する必要があります。

さらに、Kubernetes の管理者は、Kubernetes がセキュリティの懸念に対してどのようなツールをネイティブで提供しているか、また、ギャップを埋めるためにどのタイプのサードパーティ製セキュリティツールをクラスターに統合する必要があるかを知っておく必要があります。Kubernetes はセキュリティプラットフォームではありませんが、ロールベースのアクセス制御（RBAC）などの特定の種類のネイティブセキュリティツールを提供しているため、やはり複雑なトピックです。

Kubernetes の利用が初めてであり、全体の仕組みをまだ理解できていない場合、圧倒的に難しくて安全性を確保する方法まではわからないと思うかもしれません。しかし、これらの概念は、理解しやすいサイズに分割してしまえば、実はとてもシンプルです。この記事では、Kubernetes セキュリティのさまざまな側面を紹介し、それぞれの基礎と、各レイヤおよびサービスレベルにおける Kubernetes セキュリティのベストプラクティスについて説明します。

Kubernetes セキュリティの各要素

Kubernetes のセキュリティに対応する最もシンプルな方法は、Kubernetes スタックの各部分に影響を与えるリスクの種類について考え、それらを保護するために利用できるツールやリソースを特定することでしょう。

ノードセキュリティ

ノードとは、Kubernetes クラスターを構成するサーバーのことです。ほとんどのノードはいずれかのバージョンの Linux を実行しますが、ワーカーノードは Windows を実行することもあります。ノードには仮想マシンやベアメタルサーバーがありますが、セキュリティの観点では、その違いはあまり重要ではありません。

Kubernetes ノードのセキュリティには、あらゆる種類のサーバーと同じセキュリティ戦略を採用する必要があります。これには次のものが含まれます。

攻撃対象を最小化するために、無関係なアプリケーション、ライブラリ、およびオペレーティングシステムのその他のコンポーネントを削除します。ベストプラクティスは、Alpine Linux のような最小限の Linux ディストリビューションでノードをプロビジョニングすることです。
不要なユーザーアカウントを削除します。
どうしても必要なとき以外は root として実行しないようにします。
可能であれば、AppArmor や SELinux のような OS を強化するフレームワークを導入します。
OS のログを収集して分析し、潜在的な侵害を検出します。

環境の種類を問わず、オペレーティングシステムレベルでサーバーを保護した経験があるなら、Kubernetes ノードのセキュリティの扱い方はすでにご存知でしょう。ノードレベルでは、Kubernetes を実行しているノードを扱う場合も、セキュリティに関する考慮事項は他の種類のサーバーと何ら変わりません。

また、マスターノードのセキュリティとワーカーノードのセキュリティに根本的な違いもありません。マスターノードで侵害が発生するとクラスターに大きなダメージを与える可能性があるため、マスターノードのセキュリティはやや重要度が高くなりますが、マスターノードのオペレーティングシステムを保護する手順はワーカーノードと同じです。

Kubernetes API のセキュリティ

Kubernetes API は、クラスターのさまざまな要素を結び付けるものです。そのため、Kubernetes の中でも特にセキュリティが重要なリソースの 1 つです。

Kubernetes API は、デフォルトでセキュリティが確保される設計になっています。そのため、認証と承認を適切に行えるリクエストにのみ応答します。

とは言うものの、API の認証と承認は、自分が構成した RBAC ポリシーによって管理されます。したがって、API の安全性は RBAC ポリシーの安全性にかかっています。最小権限の原則を適用し、権限を細かく割り当てる安全な RBAC ポリシーを作成することが、Kubernetes API のセキュリティを確保するための基本的なベストプラクティスです。

また、アドミッションコントローラを活用すれば、API のセキュリティをさらに強化できます。アドミッションコントローラは、API サーバーによる認証と承認のあとにリクエストを評価します。このように、アドミッションコントローラは許可してはならないリクエストに対し、オプションとして第 2 の防御層を提供します。アドミッションコントローラを有効にして構成すると、API リクエストに関連するさまざまなセキュリティルールを適用できます。使用できるルールについては、こちらをご覧ください。

最後に、安全な証明書を構成し、localhost ではなくセキュアポートでリクエストを実行することを API サーバーに要求すれば、API リクエストをネットワークレベルで保護できます。

Kubernetes のネットワークセキュリティ

Kubernetes のネットワークセキュリティは、あらゆるネットワークの保護に使用されるベストプラクティスに従うことから始まるという点で、ポッドセキュリティと似ています。

ワークロードとパブリックインターネットを接続する必要があるのであれば、できる限りこれを分離するネットワークアーキテクチャを確実に構築します。ファイアウォールをゲートウェイレベルでデプロイし、問題のあるホストからのトラフィックをブロックするようにしてください。また、ネットワークトラフィックを監視して、侵入の兆候がないかを確認します。これらの手順はすべて、サービスメッシュなどの外部ツールを使用して実行できます。

ただし、Kubernetes にも、ネットワークリソースを保護するためのネイティブツールがわずかに用意されています。これらのツールはネットワークポリシーの形で提供されます。ネットワークポリシー自体はセキュリティ機能ではありませんが、管理者はこれらを使用して Kubernetes クラスター内のトラフィックフローを制御できます。

たとえば、ポッド同士をネットワークレベルで分離したり、受信トラフィックをフィルタリングしたりするネットワークポリシーを作成できます。

ネットワークポリシーは、Kubernetes 以外のネットワーク構成を保護することはできませんが、ネットワークアーキテクチャ全体に組み込み、セキュリティルールを補完する追加のリソースとして使用できます。

Kubernetes のポッドセキュリティ

Kubernetes におけるポッドとは、アプリケーションの実行に使用するコンテナまたはコンテナの集合体を指します。そのため、アプリケーションを保護するにはポッドを保護する必要があります。

ポッドセキュリティを確保するには、Kubernetes 以外での作業が必要になることがあります。デプロイ前にアプリケーションのセキュリティテストを実施し、コンテナイメージの実行前にスキャンしてください。ポッドからログを収集し、それを分析して潜在的な侵害や不正使用を検出します。

ただし、Kubernetes にはすでに実行されているポッドのセキュリティを強化できるネイティブツールがいくつか用意されています。これには次のものが含まれます。

RBAC ポリシー: クラスター内のユーザーおよびサービスによるポッドへのアクセスを管理できます。
セキュリティコンテキスト: ポッドを実行する特権レベルを定義します。
ネットワークポリシー: （前述のとおり）ポッドをネットワークレベルで分離できます。
アドミッションコントローラ: RBAC に基づいて設定したルールを実質的に拡張する追加ルールを適用できます。

使用するポッドセキュリティツールの種類と構成方法は、ワークロードの性質によって決まります。ポッドセキュリティに万能なアプローチはありません。たとえば、ネットワークレベルで完全に分離できるポッドもあれば、通信が必要なポッドもあります。

しかし、具体的な要件がどのようなものであれ、Kubernetes ポッドの保護に使用できるリソースを評価し、それを最大限に活用する必要があります。

Kubernetes のデータセキュリティ

Kubernetes は、実行中のポッド内に存在する非永続データとノードに保存されるログデータを除き、データを一切保存しません。通常、クラスターが作成、アクセスするデータは、ストレージプラグインを介して Kubernetes とやり取りする何らかの外部ストレージシステムに保存されます。

そのため、Kubernetes に関連するデータを保護するには、大規模ストレージシステム内のデータ保護のベストプラクティスに従う必要があります。保存データを可能な限り暗号化し、データにアクセスできるユーザーをアクセス制御ツールによって制限し、ストレージプールを管理するサーバーが適切にロックダウンされていることを確認します。また、データをバックアップすることで、データの盗難やランサムウェア攻撃から保護します。

Kubernetes のポッドやノード内にネイティブに存在する比較的量の少ないデータについては、それを保護するための特別なツールは用意されていません。しかし、前述したベストプラクティスを使用してポッドとノードを保護すれば、このようなデータも保護できます。

Kubernetes のその他のセキュリティリソース

前述したコンポーネント固有のセキュリティ対策に加え、管理者は Kubernetes のその他のセキュリティリソースについても知っておく必要があります。

監査ログ

Kubernetes では、クラスター内で実行されたアクション、それを実行したユーザー、およびそれによる結果を、必要に応じて細かく記録できます。これらの監査ログを使用することによって、クラスターを包括的に監査し、潜在的なセキュリティの問題をリアルタイムで検出したり、セキュリティインシデントの事後調査を実施したりできます。

監査ログを使用するには、最初に監査ポリシーを作成し、Kubernetes がどのようにイベントを記録するかを定義しておく必要があります。Kubernetes のドキュメントでは、監査ポリシーの作成について詳しく説明しています。

また、Kubernetes は監査ログを大規模に分析できるツールを備えていないため、異常の検出や侵害の警告を実行できる外部のモニタリングプラットフォーム、またはオブザーバビリティプラットフォームに監査ログをストリーミングする必要があります。そうしないと、監査イベントを手動で監視しなければならず、大規模な環境では現実的ではありません。

Namespace

Kubernetes では、namespace を使用して異なるワークロードをそれぞれ分離できます。

すべてを単一の namespace で実行することもできますが、セキュリティの観点から見たベストプラクティスでは、チームごと、あるいはワークロードの種類ごとに異なる namespace をクラスター内に作成します。たとえば、別々の namespace を使用して、開発/テスト環境と本番環境を分離する場合などです。

複数の namespace を管理する場合、（必ずではありませんが）多くのケースで namespace ごとに異なる RBAC ポリシーを作成する必要が生じるため、Kubernetes の管理が少し複雑になります。しかし、侵害の潜在的な影響を最小限に抑えられるため、手間をかける価値は十分にあります。

Kubernetes で外部のセキュリティツールを使用する

Kubernetes は、クラスター内で実行されているリソースを強化するための特定の種類のツールを提供しますが、セキュリティインシデントを検出、管理するようには設計されていません。

Kubernetes のセキュリティを大規模に管理するには、外部のセキュリティツールを活用するのが最も現実的です。これらのツールは、次のようないくつかの重要なセキュリティ機能を実行できます。

RBAC ポリシーやセキュリティコンテキストなどの構成データをスキャンして、セキュリティの問題を引き起こす可能性のある不適切な構成を特定します。
アプリケーションとコンテナイメージのスキャン機能を提供します。この機能は Kubernetes クラスターにデータを供給する、自動化されたセキュリティパイプラインの構築に使用できます。
アプリケーションログと監査ログの収集、集計、分析を行い、侵害の兆候が疑われる異常の検出に役立てることができます。

Kubernetes 用の外部セキュリティツールにはさまざまなものがあります。もちろん、DevOps チームが Kubernetes やその他のクラウドネイティブ環境のすべての層を保護するために開発された Sysdig もその 1 つです。