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

Kubernetesのネットワークセキュリティは特に難しい、とされています。

ネットワークは様々な方法で構成できますが、Kubernetesの中でも特に複雑な部分です。サービスメッシュを使うかもしれませんが、使わないかもしれません。クラスタ内のリソースの中には、内部ネットワークとのみインターフェイスするものもあれば、インターネットへの直接アクセスを必要とするものもあります。ポート、IPアドレス、そしてその他のネットワーク属性は通常動的に構成されます。

選択肢が多岐に渡り、適切な構成が場合によって違い、ネットワークレベルで何が起こっているかを追跡しにくいです。そんな環境を保護するには、ネットワークアーキテクチャを深く理解したうえで、Kubernetesが提供するネットワークポリシーや、ネットワークをさらに強固にするサードパーティ製ツールなどにも精通していなくてはなりません。

この記事では、「ネットワークがどのように機能するのか」、「どのようなセキュリティリスクがあるのか」など、Kubernetesのネットワークセキュリティを説明。入門から実践まで、Kubernetesのネットワークをセキュアに保つために知っておきたい知識を集めました。

関 連 記 事

クラウドセキュリティと
ランタイムインサイト

Kubernetesネットワークの概要

ネットワークレベルでのセキュリティを実現する前提として、Kubernetesのネットワーキングを学びましょう。「Kubernetesがどのようにネットワークを処理するか」という基本的な概要を知ることで、実際の環境を理解しやすくなります。

ネットワークの目的

Kubernetesでは、ネットワークは主に2つの目的を果たします：:

• 内部ネットワーク： ネットワークは、クラスタ内のポッド、Kubernetesノード、およびその他のリソース間の通信を促進する内部トラフィックを処理します。通常、内部ネットワークはプライベートサブネットとIPアドレスを使用し、パブリックインターネットから隔離されています。
• 外部ネットワーク： インターネットに接続する必要があるワークロードは、パブリックIPアドレスを使用します。

Kube-Proxy

Kubernetes内のトラフィックフローを管理するサービスがkube-proxyです。Kube-proxyはKubernetesクラスタの各ノード上で実行され、コンテナのIPアドレスとポートに基づいて、それらのノード上でホストされているコンテナにパケットを転送します。

バックエンドでは、kube-proxyはLinuxのiptablesのようなOSレベルのネットワークサービスに依存してトラフィックを制御します。しかし、kube-proxyはこれらのサービスをKubernetesのリソースから抽象化しているため、Kubernetesのネットワークセキュリティの観点からは、ノードレベルの基礎となるネットワーク管理レイヤーは特に重要ではありません。

CNIプラグイン

多くの場合、KubernetesはContainer Network Interface（CNI）プラグインを使用して、コンテナが使用できる仮想ネットワークインターフェースを作成します。CNIプラグインは、パブリッククラウド上でネイティブに動作するもの（Azure Virtual NetworksやAWS Network Interfacesなど）など、さまざまなサードパーティのネットワーク構成管理プラットフォームとKubernetesを統合するために使用できます。

また、Weave NetのようなプラットフォームをサポートするCNIプラグインも用意されており、異種環境やハイブリッド環境（Kubernetesとパブリッククラウドやプライベートデータセンターなど、複数の種類のプラットフォームを組み合わせた環境）でネットワーク構成を標準化する方法を提供するように設計されています。

技術的には、CNIプラグインを使わずにKubernetesでネットワークを構成することができます。しかし、大半の実稼働クラスターはCNIを使ってネットワーク管理をおこなっているのが現状です。

サービスメッシュ

Kubernetesクラスターは通常、ネットワークをシンプル化するためにサービスメッシュを活用します。

サービスメッシュは、ネットワーク上のさまざまなリソースの検出を自動化できます。これにより、ネットワークの可観測性を確保しつつ、セキュリティ機能しやすくなるでしょう。

なおKubernetes自体は公式のサービスメッシュを提供しているわけではありません。Istio、Traefik、NGINX などのよく使われるサービスメッシュと統合することで活用可能です。

動的な構成（Dynamic Configuration)

どのCNIプラグイン、サービスメッシュ、その他のネットワークツールをKubernetesで使用するにしても、多くの場合、ネットワーク設定は非常に動的です。

つまり、ノード、ポッド、およびサービスのIPアドレスとポートは、それらのリソースが作成されるときに随時設定されます。管理者は、Kubernetesが割り当てに使用するIPアドレスのプールを定義できます。ただしKubernetesの公式ツールでは）静的IPアドレスを割り当てることはできません。

動的な設定は、ある面でKubernetesのネットワークセキュリティを難しくする要因です。たとえば、仮想マシンで作業するときのように、静的なアドレス構成に基づいてホストをホワイトリストやブラックリストに登録することはできません。

Kubernetes内部では、ネットワークトラフィックデータを特定のリソースにマッピングしにくくなります。たとえば、指定されたIPアドレスが1つのポッドまたはノードだけで使用されたのか、あるいは1つのリソースで使用され、最初のリソースがシャットダウンしたときに別のリソースに再割り当てされたのかを常に把握できるとは限らないからです。

Kubernetesネットワークの保護方法

Kubernetesは通常、内部リソース（kube-proxyなど）と外部サービス（CNIプラグインやサービスメッシュなど）のミックスに依存してネットワーク構成とトラフィックを管理します。

そのため、Kubernetesネットワークのセキュリティを確保するには、管理者が公式ツールとサードパーティツールを組み合わせての活用も有効です。

ネットワークポリシーの定義

ネイティブでは、Kubernetesがネットワークセキュリティのために提供する最も重要なリソースはネットワークポリシーです。簡単に言うと、ネットワークポリシーは、ネットワークレベルでポッドが互いにどのように通信できるかを管理するルールを定義します。

ポッドの通信を制御する体系的な手段を提供するだけでなく、ネットワークポリシーには、管理者がポッドのラベルや名前空間などのコンテキストに基づいてリソースと関連するネットワークルールを定義できるという重要な利点があります。Kubernetesのネットワーク構成の動的な性質を考えると、IPアドレスを使用してネットワークルールを管理することはできないため、これは非常に重要です。

ネットワークポリシーはKubernetesのRBACポリシーに似ています。どのネットワークルールを適用するかを指定するファイルで、ルールが適用されるリソース（ネームスペース、ポッドなど）も特定します。

例えば、このネットワークポリシーは、"default "ネームスペースを実行しているポッド間のバックエンドのイグジットを防ぎます：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-backend-egress
namespace: default
spec:
podSelector:
matchLabels:
tier: backend
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
tier: backend

ネットワークポリシーの限界

ネットワークポリシーはKubernetesのネットワークセキュリティにとって重要なツールですが、その限界を認識することが重要です：

• ポッドにフォーカスしている： ネットワークポリシーは基本的にポッドのネットワークアクセスを分離または制限するために設計されています。Kubernetesのノードやその他のリソースのネットワークルールの管理には（少なくとも直接的で単純な方法では）使用できません。
• 不正使用は検出できない： ネットワークポリシーは、ネットワークアクセスをロックし、潜在的なセキュリティホールを塞ぐための素晴らしい方法です。しかし、潜在的なセキュリティ問題を検出したり警告したりすることはできません。
• データを暗号化しない：　 ネットワークポリシーは、Kubernetesのコンポーネント間を移動するデータを暗号化することはできません。ネットワークの暗号化を実現するには、サードパーティのツール（サービスメッシュなど）を使用する必要があります。

サードパーティツールの活用

Kubernetesのネイティブネットワークセキュリティツールに関しては、基本的にネットワークポリシーがすべてです。ネットワークセキュリティの他の側面に対処するには、外部ツールを活用する必要があります。

Kubernetes用の様々なサードパーティネットワーキングソリューションで利用できる特定のセキュリティツールと機能は様々であるため、外部ツールを使ってネットワークセキュリティ要件に対応するための万能のソリューションはありません。

しかし、一般的には、サービスメッシュを利用することで、トラフィックの暗号化、ネットワークに接続されたリソースの認証と認可の実施、Kubernetesネットワークリソースからのテレメトリデータの収集が可能になります。Kubernetesネットワークポリシーを使用して現実的でないネットワークセキュリティルールを実施するために使用できるポリシーフレームワークも提供できるものもあります。

CNIプラグインは多くの場合、ポリシーフレームワークやネットワーク監視機能など、同様の機能を備えています。Kubernetesのネットワークセキュリティを最大化するために必要な可視性とポリシーの実施を提供するために、「CNIに接続されたネットワーキングプラットフォームか、またはサービスメッシュに主に依存するか」を選択できます。

Kubernetesセキュリティのベストプラクティスに倣う

Kubernetesネットワークのセキュリティ確保に役立つさまざまなツールを活用するだけでなく、Kubernetesクラスターをホストする環境でネットワークリソース全般を扱う際に従うべき標準的なベストプラクティスがあります。

• RBACの使用： Kubernetes Role-Based Access Control（RBAC）はネットワークセキュリティのフレームワークではありませんが、RBACルールはクラスタ内のリソースへのアクセスを制限することで、ネットワークに起因する脅威の影響を緩和するのに役立ちます。
• デフォルトポートを回避： Kubernetesはそのサービスのほとんどにデフォルトのポートを使用しています。ネットワークセキュリティを強化するには、カスタムポートを選択することで、攻撃者がリソースを見つけにくくなります。
• 外部でネットワークをセグメント化： ネットワークポリシー、サービスメッシュルール、その他のリソースを使用してKubernetes内部のネットワークを分離することができます（そして、そうする必要があります）。クラスタをホスティングしている場所にもよりますが、これはVPCやローカルファイアウォールなどのリソースを活用して、パブリックインターネットへのリソースの露出を最小限に抑えることを意味します。
• 監査ログの活用： Kubernetesの監査ログは、Kubernetes内で実行されたすべてのリソースリクエストの記録を提供します。監査ログを有効にして分析することで、ネットワーク上の侵害の兆候となり得る挙動を検出する可能性を最大限に高めることができます。

まとめ

ネットワークはKubernetesの中でも特に複雑な部分です。セキュリティ対策をおこなうには、Kubernetesネットワーキングの概要を知る必要があります。
保護方法としては、Kubernetes公式のネットワークポリシーをふまえつつ、サードパーティ製ツールを活用するのが王道です。