Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2022年2月28日現在における、Sysdig Cloud Native Learning Hub上のHow to Design the Most Secure Kubernetes Architecture(https://sysdig.com/learn-cloud-native/kubernetes-security/secure-kubernetes-architecture/) を元に日本語に翻訳・再構成した内容となっております。
Kubernetes環境には、さまざまな形態や規模があります。中には、本質的に他のものよりも安全なものもあります。
言い換えれば、Kubernetesアーキテクチャー（Kubernetes環境を設計する際に選択するアーキテクチャー戦略）は、全体的なセキュリティに重要な影響を与える可能性があるということです。マルチクラスター環境は、すべてを単一クラスターで実行する環境よりも、ある面ではより安全かもしれません（しかし、複数のクラスターがあると複雑さが増し、セキュリティの観点からは不利になります）。同様に、モニタリング・エージェントやサービス・メッシュなど、Kubernetesアーキテクチャーに組み込むことを選択したサードパーティ・ツールにも、セキュリティ上の影響があります。
では、どのようなアーキテクチャー戦略がKubernetesの最強のセキュリティ態勢につながるのでしょうか。この記事では、Kubernetes環境を計画する際に管理者が通常行わなければならないハイレベルな設計上の選択について説明し、また、セキュリティの観点から見た各要素の意味について議論することで、この問いに対する答えを提供します。
マネージドKubernetesサービス vs セルフマネージドKubernetes
Kubernetesのインストールを計画する際に、おそらく今日ほとんどのチームが自問する最初の質問は、マネージドKubernetesサービス（Amazon AKS、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ポリシーの更新といったタスクを簡単に処理できるようになります。
単一のネームスペースと複数のネームスペース
複数のクラスターを運用しない場合でも、複数のネームスペースを作成することで、かなり強力なワークロードの分離を実現することができます。ネームスペースは基本的に、同じ物理クラスター内でホストされる仮想クラスタです。
一般的には、Kubernetesで実行するアプリケーションごとに異なるネームスペースを作成することになります。また、dev/testingとproductionで異なるネームスペースを作成する必要があります。
ただし、ネームスペースが提供する分離には限界があることを忘れないでください。ClusterRolesで割り当てたパーミッションは、すべてのネームスペースに適用されます。この意味で、複数のネームスペースを持つことは、各ネームスペース内でユーザーとアカウントを分離できるRBACポリシーを作成する場合にのみ有益です。可能な限り、クラスターロールの代わりにロールを使用してパーミッションを割り当てることで、これを実現します。
サービスメッシュ
Kubernetesクラスター内部で動作するリソースのサービス発見と接続を管理するサービスメッシュは、一握りのサービス以上を含むKubernetes環境にとって重要なツールです。
全体として、サービスメッシュはKubernetesのセキュリティ面においてプラスに働きます。接続性の管理を支援するだけでなく、ほとんどのサービスメッシュは、セキュリティ脅威を検出するのに役立つ監視および警告機能も提供しています。Kubernetes自体はネットワーク関連のセキュリティインシデントを記録しないため（Kubernetesの監査イベントはネットワークをカバーせず、APIのみ）、サービスメッシュは重要なセキュリティ可視性のギャップを埋めることができます。
サービスメッシュの欠点は、Kubernetesの全体的な攻撃対象領域と複雑さを増大させることです。サービスメッシュに侵入することに成功した攻撃者は、それを橋頭堡としてクラスター（または複数のクラスター）全体に侵入することができます。
とはいえ、サービスメッシュを安全にデプロイする限り、関連するリスクを軽減することができる。アプリケーションポッドと一緒に実行されるサイドカーコンテナ経由でサービスメッシュソフトウェアをデプロイする場合は、必ずサイドカーを分離し、RBACとネットワークポリシーを使用してアクセスをロックダウンしてください。
外部監視・セキュリティソフト
サービスメッシュに加えて、サードパーティのパフォーマンスおよびセキュリティ監視ソフトウェアを導入して、クラスターの管理を支援することも一般的です。
これらのツールは、攻撃対象領域を増やすことにもなります。しかし、安全に導入する限り、そのメリットはリスクをはるかに上回ります。
外部ツールのセキュリティは、以下のような方法で最適化することができます。
- 前述のとおり、サイドカーコンテナとして実行されるエージェントには最小権限を強制する。
- 可能な限り、Webhookを使用してKubernetesから外部ツールにデータをストリーミングします。そうすることで、ツールをクラスター内で直接実行する必要がなくなり、分離して実行するよりも大きなセキュリティリスクをもたらすことを回避できます。
- 外部ツールが生成したり永続的に保存したりするデータは、必ずセキュアにしてください。Kubernetesの監査ログに含まれるような情報は、攻撃者がクラスターにアクセスするのに役立つ可能性があるため、そのデータの管理方法には注意が必要です。
最も安全なKubernetesアーキテクチャーのデザイン
結局のところ、安全なKubernetesアーキテクチャーのデザインに、万能なアプローチはありません。アーキテクチャーの決定には、通常、環境の規模、そこで実行しているワークロードの種類、環境を共有しているユーザーやチームの数が反映されます。小規模な環境では、設計がよりシンプルになり、必要な外部ツールも少なくなる可能性が高いため、デフォルトでより強固なセキュリティポスチャーが実現されることになります。
しかし、複雑な環境（複数のクラスターやさまざまなサードパーティの統合を伴う環境）は、アーキテクチャー的に単純な構成と同様に安全性を確保する事ができます。
したがって、安全なKubernetes環境を設計するための鍵は、特定のタイプの構成を避けたり、特定のツールを確実に入れたり入れなかったりすることではありません。Kubernetesのアーキテクチャーを複雑にするたびに、その決定がもたらすセキュリティへの影響を特定し、対処することを確実にすることが求められます。