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

Table of contents

This is the block containing the component that will be injected inside the Rich Text. You can hide this block if you want.

初めて採用する方にとって、Kubernetes のセキュリティ確保は、一見すると難しい作業に思えるかもしれません。そもそもKubernetes はさまざまなコンポーネントで構成される非常に複雑なシステムです。各構成要素を理解した上でセキュリティリスクのタイプごとに対策する必要があり、モジュールを有効にしたり、ツールをインストールしたりするだけでは安全性を確保するのは難しいのが現状です。

しかし、これらの概念は実はとてもシンプルです。まずは理解しやすいサイズに要素を分割し、順番に把握することから始めてみましょう。

この記事では、Kubernetesのセキュリティに初めて触れる初心者向けの基礎知識として、各要素とリスクの種類、ベストプラクティスをわかりやすく解説します。

Kubernetes セキュリティが複雑になる理由

コンテナオーケストレーターのKubernetesにおいて、セキュリティが複雑になる理由は、その構造にあります。

Kubernetesは、さまざまなコンポーネントで構成されており、非常に複雑です。一般的なシステムのように、セキュリティモジュールを有効にしたり、セキュリティツールをインストールしたりするだけでは保護できません。

セキュリティ対策を進めるには、Kubernetes クラスター内のさまざまなレイヤやサービスに影響を及ぼす可能性のあるリスクのタイプごとに対処する必要があります。たとえば、ノード、ネットワーク、Pod（ポッド）、データなどを保護する方法をそれぞれ理解し、個別に対処していくことで、安全性を高めることが可能です。

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

Kubernetes セキュリティの各要素

Kubernetes で考えたいセキュリティを、要素ごとに分割し解説します。

コンポーネントの概要を把握したうえで、スタックの各部分に影響を与えるリスクの種類を分析します。利用できるツールやリソースを特定できれば、適切に対処しやすくなるはずです。

ノードのセキュリティ

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

ノードを保護するには、あらゆる種類のサーバーと同じセキュリティ戦略を採用するのが一般的です。例えば、以下が含まれます。

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

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

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

Kubernetes API のセキュリティ

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

そもそもデフォルトでセキュリティが確保される設計になっているため、認証と承認を適切に行えるリクエストにのみ応答します。ただしAPI の認証と承認は、自分が構成した RBAC ポリシーによって管理されていることから、そのAPI の安全性は RBAC ポリシーの安全性にかかっています。

よって、Kubernetes APIのセキュリティを確保するための基本的なベストプラクティスは、「最小権限の原則を適用し、権限を細かく割り当てる安全な RBAC ポリシーを作成すること」ことです。さらに、アドミッションコントローラを活用すれば、API のセキュリティをさらに強化できます。

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

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

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

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

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

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

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

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

Kubernetes のPodセキュリティ

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

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

ただし、Kubernetes にはすでに実行されているPodのセキュリティを強化できるネイティブツールが用意されています。例えば、以下が含まれます。

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

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

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

Kubernetes のデータセキュリティ

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

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

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

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 つです。

まとめ

Kuberneteのセキュリティでは、クラスター内のさまざまなレイヤやサービスに影響を及ぼす可能性のあるリスクのタイプごとに対処する必要があります。まずは各要素へ分解し、それぞれの概要と、特有の対処方法を把握するのが近道です。

あわせて監査ログ、Namespaceなど他のセキュリティリソースについて知ったり、外部ツールを適切に組み合わせたりすることで、さらに安全性を高めることができます。

FAQs

No items found.

セキュリティ専門家とともに、
クラウドを防御する正しい方法を試してみよう

デモを依頼