最も安全な Kubernetes アーキテクチャを設計する方法

Kubernetes 環境の形状、形態、規模はさまざまです。中には、本質的に他の環境よりも安全なものもあります。

言い換えれば、Kubernetes アーキテクチャ（Kubernetes 環境を設計する際に選択するアーキテクチャ戦略）は全体的なセキュリティに重要な影響を及ぼす可能性があります。マルチクラスター環境は、すべてを単一のクラスターで実行する環境よりも、ある意味では安全かもしれません（ただし、マルチクラスターは複雑さも増すため、セキュリティの観点で見るとデメリットになります）。また、監視エージェントやサービスメッシュなど、Kubernetes アーキテクチャに組み込まれるサードパーティツールにもセキュリティ上の影響があります。

では、どのようなアーキテクチャ戦略であれば Kubernetes の最も強力なセキュリティ体制を構築できるのでしょうか。この記事では、Kubernetes 環境を設計する際に管理者が必ず直面する高度な設計上の選択について説明し、セキュリティの観点から見た各要素の意味について考察することによって、この問いに対する解決策を導き出します。

マネージド Kubernetes サービスと自己管理型 Kubernetes

現在、Kubernetes の導入を計画する際にほとんどのチームが考えるべき最初の項目はおそらく、マネージド Kubernetes サービス（Amazon EKS や Azure Kubernetes Service など、パブリッククラウドで実行される Kubernetes プラットフォーム）を使用するか、自社で管理するインフラストラクチャに Kubernetes をデプロイして自ら管理するかということでしょう。

マネージド Kubernetes サービスでは、クラスターの稼働を維持するために必要なプロビジョニングタスクとメンテナンスタスクの少なくとも一部を Kubernetes プロバイダが担うため、多くの場合はセットアップとメンテナンスが容易です。（ベンダーが提供する管理機能の範囲は 「マネージド」Kubernetes サービスによって大きく異なる場合がありますが、その違いはこの記事で扱う内容とほとんど関係ありません。）

また、マネージド Kubernetes は 2 つの重要な点でより安全である可能性があります。

ホストインフラストラクチャは専門家が管理し、セキュリティ脅威を監視しています。つまり、マネージド Kubernetes では、ノードの OS レベルでのセキュリティ問題をそれほど心配する必要がありません。 マネージド Kubernetes プロバイダは、セキュリティの観点から見て、（少なくともほとんどの場合は）ベストプラクティスに準拠している事前構成済みの設定やツールを提供することがあります。

一方、マネージド Kubernetes アーキテクチャは、ベンダーが所有するツールと（ほとんどの場合は）インフラストラクチャを使用するため、ユーザーが確保できるコントロールとプライバシーが制限されるというセキュリティ上の固有の欠点があります。たとえば、クラスターをインターネットから「エアギャップ」する必要がある場合はマネージド Kubernetes サービスを使用できません。また、特定の種類のマネージド Kubernetes プラットフォーム（Platform9など）はオンプレミスのインフラストラクチャと互換性がありますが、ほとんどはパブリッククラウドでホストされているインフラストラクチャを使用しなければならず、セキュリティの脅威にさらされる可能性が高くなります。

結論: Kubernetes の導入が初めてであり、Kubernetes のセキュリティ原則に精通していない場合は、マネージド Kubernetes サービスの方が自分でセットアップするよりも安全な環境を確保しやすくなります。しかし、エアギャップなどの機能を含む高度なセキュリティアーキテクチャが必要な場合は、環境のセットアップと管理を自ら行う必要があるでしょう。

シングルクラスターとマルチクラスターの Kubernetes アーキテクチャ

Kubernetes の導入を計画する際に必要となる、アーキテクチャに関するもう 1 つの重要な決定は、クラスターを 1 つだけセットアップするか、複数のクラスターをセットアップするかということです。

従来は、ほとんどのチームが単一のクラスターを使用していました。しかし CNCF によると、ワークロード間の高度な分離が可能であるという理由から、マルチクラスター環境の人気が高まりつつあります。ワークロードごとに異なるクラスターにデプロイすることによって、あるワークロードのセキュリティの問題が他のワークロードに「波及」するリスクを大幅に抑えることができます。Kubernetes クラスターのセキュリティについて、詳しくはこちらをご覧ください。

とはいえ、チームはこのセキュリティ上のメリットと、マルチクラスター Kubernetes の大きな欠点である複雑さの増大を比較して検討する必要があります。クラスターが増えるということは、追跡が必要な監査ログ、作成と適用と監視が必要な RBAC ポリシー、構成と分離が必要なネットワークなどが増えるということです。

クラスターの管理と監視に強力な自動化を導入していれば、このような複雑さの増大はそれほど問題にならないかもしれません。その場合は、マルチクラスターアーキテクチャを採用しましょう。ただし、このようなセットアップのすべてを把握するのが難しければシングルクラスターを選びましょう。シングルクラスターなら、セキュリティイベントの検出や RBAC ポリシーの更新などのタスクを簡単に処理できます。

単一の namespace と複数の namespace

複数のクラスターを実行しなくても、namespace を複数作成することによって、非常に強力なワークロード分離を実現できます。namespace とは、要するに同じ物理クラスター内でホストされる仮想クラスターのことです。

通常は、Kubernetes で実行するアプリケーションごとに異なる namespace を作成します。また、開発/テストと実稼働用にも異なる namespace を作成した方がよいでしょう。

ただし、namespace による分離には限界があることを忘れないでください。ClusterRole で割り当てた権限は、すべての namespace に適用されます。そのため、複数の namespace が役に立つのは、各 namespace 内でユーザーとアカウントを分離できる RBAC ポリシーを作成する場合のみです。これを実現するには、可能な限り ClusterRole ではなく Role を使用して権限を割り当てます。

サービスメッシュ

Kubernetes クラスター内で実行されているリソースのサービス検索と接続を管理するサービスメッシュは、ある程度のサービスが含まれている Kubernetes 環境にとって重要なツールです。

全体として、サービスメッシュは Kubernetes のセキュリティにとってプラスになります。接続の管理に役立つだけでなく、ほとんどのサービスメッシュは、セキュリティ脅威の検出に役立つ監視機能とアラート機能も提供しています。Kubernetes 自体はネットワーク関連のセキュリティインシデントを記録しないため（Kubernetes の監査イベントは API にのみ対応し、ネットワークには対応しません）、サービスメッシュがセキュリティの可視性に関する重大なギャップを解消します。

サービスメッシュの欠点は、Kubernetes の攻撃対象を全体的に拡大し複雑さを増大させることです。サービスメッシュへの侵入に成功した攻撃者は、それを足掛かりとして、単一または複数のクラスター全体に侵入できます。

とはいえ、サービスメッシュを安全にデプロイしていれば、関連するリスクを抑えることができます。アプリケーションポッドと共に実行されるサイドカーコンテナを介してサービスメッシュソフトウェアをデプロイする場合は、必ずサイドカーを分離し、RBAC ポリシーとネットワークポリシーを使用してアクセスをロックダウンしてください。

外部監視とセキュリティソフトウェア

サービスメッシュに加えて、サードパーティのパフォーマンスやセキュリティ監視ソフトウェアを導入してクラスターの管理に利用することもよくあります。

これらのツールは攻撃対象を増やすことにもなりますが、安全にデプロイする限り、メリットはリスクをはるかに上回ります。

外部ツールのセキュリティは、以下のような方法で最適化できます。

前述のとおり、サイドカーコンテナとして実行されるエージェントには最小権限を適用します。 可能であれば、Webhook を使用して Kubernetes から外部ツールにデータをストリーミングします。こうすればクラスター内で直接ツールを実行する必要がなくなり、分離して実行するよりもセキュリティリスクが高くなることを回避できます。 外部ツールによって生成または永続的に保存されるデータは、必ずセキュリティで保護します。Kubernetes 監査ログに含まれているような情報は、攻撃者がクラスターにアクセスするのに利用される可能性があるため、そのようなデータの管理方法には注意が必要です。

最も安全な Kubernetes アーキテクチャの設計

結局のところ、安全な Kubernetes アーキテクチャを設計するための万能なアプローチはありません。通常、アーキテクチャの決定には、環境の規模、そこで実行されているワークロードの種類、その環境を共有するユーザーやチームの数などを考慮します。環境が小さければ、設計もシンプルで必要な外部ツールも少なくなる可能性が高いため、デフォルトでより強固なセキュリティ体制を構築できます。

しかし、複雑な環境（複数のクラスターやさまざまなサードパーティの統合を伴う環境）でも、シンプルなアーキテクチャ構成と同等の安全性を確保することは可能です。

つまり、安全な Kubernetes 環境の設計に重要なことは、特定の種類の構成を避けたり、特定のツールを採用または除外するようなことではありません。Kubernetes アーキテクチャが複雑になる度に、その決定がセキュリティにもたらす影響を確実に特定して対処することです。