Kubernetesネットワークポリシーのベストプラクティス

Kubernetes Pod内でコンテナ化されたワークロードのトラフィックを制御・フィルタリングすることは、従来型のネットワーク環境におけるファイアウォールと同様に重要です。このシナリオでは、そうした機能をKubernetes NetworkPolicy APIが提供します。

この記事では、ネットワークポリシーの例を作成し、主要なパラメーターを確認しながら、Kubernetes NetworkPolicyについて解説します。次に、一般的なNetworkPolicyのユースケースを取り上げ、kubectlを使った監視方法を紹介します。最後に、サードパーティ製のKubernetes拡張機能を使ってContainer Network Interface（CNI）を実装する方法を見ていきます。

Kubernetesネットワークポリシーをためらわずに導入すべき理由

Kubernetes環境の運用において、ネットワークポリシーの導入は不可欠です。ネットワークポリシーを設定していない場合、クラスター内のすべてのPodはデフォルトで相互に通信できます。そのため、Podに機密情報を保管するバックエンドデータベースなどの機密データが含まれる場合は、特定のフロントエンドPodだけが接続できるようにする必要があります。

また、開発環境のPodと本番環境で実行されているPodの間のネットワークトラフィックを分離することもできます。ネットワークポリシーがなければ、ネットワーク内のあらゆる場所との間で、すべてのトラフィックが自由に流れます。

幸い、Kubernetes NetworkPolicyの設定は、意図したとおりにネットワークトラフィックを流すための、シンプルで効果的かつ包括的な方法です。

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

サンプルのNetworkPolicyを見てみましょう。WordPressのフロントエンドとMySQLのバックエンドを備え、Webサービスとデータベースサービスの両方を含むPod群をKubernetesのdefaultネームスペースにデプロイした、サンプルワークロードを考えます。企業のセキュリティプロトコルでは、特定のワークロードのネットワークトラフィックを分離し、必要最小限の受信・送信トラフィックのみを許可することが求められています。

この方針には、次の条件が含まれます。

• すべてのトラフィックを許可するKubernetesのデフォルト動作をブロックする。

• defaultネームスペース内でwordpressラベルが付いたPod同士のみが通信できるようにする。

• パブリックインターネットおよび172.16.0.0のIP範囲から、ポート80/443への受信（ingress）接続を許可する。

• wordpressラベルが付いたPodだけが、ポート3306でMySQLデータベースのPodに接続できるようにする。

• Kubernetes DNSサービス（ポート53）への接続は常に許可する。

• クラスター外へのすべての送信接続をブロックする。

以下のネットワーク図は、これらのルールの構成例を示しています。

この例では、ネットワークポリシーを複数のポリシー定義ファイルに分けることも、すべてを1つのYAMLマニフェストファイルにまとめることもできます。ワークロードが1つ（webapp）なので、ルールベースの定義ファイルを1つにまとめるのが適切です。ただし、この例には複数の受信接続と送信接続があるため、クラスター内の接続ごとに個別の設定ファイルを作成する方法もあります。

ここからは、上記の設定に使われているいくつかのパラメーターを取り上げ、設定との関係やネットワークトラフィックへの影響を確認します。

APIとメタデータ

以下のYAMLファイルの1行目では、ネットワーキングAPI（networking.k8s.io）とそのバージョン（v1）を指定しています。また、YAMLファイルの種類をNetworkPolicyと定義し、ネットワークポリシーを設定することをKubernetes APIコントローラーに伝えます。metadataセクションのnameとnamespaceには、このルールセットの名前と関連付けるネームスペースを指定します。

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: sample-network-policy
5  namespace: default

YAMLファイルの次の部分にはspecsセクションがあり、ネットワークポリシーを適用するフィルターを指定できます。

以下の部分には、重要なパラメーターがいくつか含まれています。

• podSelector — 指定したトラフィックポリシーの適用対象となるPodを指定します。この例ではmatchLabelsパラメーターを使い、app: wordpressのラベルが付いたすべてのPodにネットワークポリシーを適用します。その結果、このポリシーはそれ以外のすべてのPodには適用されません。

• policyTypes — IngressとEgressの2種類があります。

• Ingress — Pod、ネームスペース、Podグループへのすべての受信トラフィックを定義します。

• Egress — Pod、ネームスペース、Podグループへのすべての送信トラフィックを定義します。

1spec:
2  podSelector:
3    matchLabels:
4      app: wordpress
5  policyTypes:
6    - Egress
7    - Ingress

次に、ネットワークポリシーのingressセクションで、許可する受信トラフィックの種類を定義します。以下の設定では、次の送信元からポート443と80への受信を許可します。

• wordpressラベルが付いたすべてのPod

• パブリックインターネットからのすべてのトラフィック（cidr: 0.0.0.0/0）

• 172.16.0.0/16の範囲内にあるすべてのIPアドレス。社内のIP範囲（VPN、VLAN、サブネットなど）を表す場合があります。

上記のトラフィックを許可するYAMLスニペットは、次のようになります。

1  ingress:
2    - from:
3      - podSelector:
4          matchLabels:
5            app: wordpress
6      ports:
7        - port: 443
8        - port: 80  
9    - from:
10      - ipBlock:
11          cidr: 172.16.0.0/16
12      ports:
13        - port: 443
14        - port: 80
15    - from:
16      - ipBlock:
17          cidr: 0.0.0.0/0
18      ports:
19        - port: 443
20        - port: 80

最後に、送信トラフィックのルールを定義するegressセクションを見てみましょう。webappラベルが付いたPodからポート1433（SQL）と53（DNS）へのすべての送信通信を許可します。

webappラベルを指定することで、他のPodがSQL Serverインスタンスと通信できなくなり、関連するセキュリティリスクを排除できます。同様に、この設定では、ポート53を使ったクラスター内のすべてのPodへの接続を許可します。

このポリシー定義には、もう1つ重要なポイントがあります。ネットワークポリシーを導入してPod間の接続を制御する場合、許可・拒否の設定を両方向で行う必要があります。バックエンドへの受信トラフィックを許可せずに、フロントエンドからの送信トラフィックだけを許可すると、通信できなくなります。

この部分のトラフィックを定義するYAMLスニペットは、次のとおりです。

1  egress: 
2    - to:
3        - namespaceSelector: {}
4          podSelector:
5            matchLabels:
6              k8s-app: kube-dns
7      ports:
8        - port: 53
9          protocol: UDP
10
11    - to:
12        - podSelector:
13            matchLabels:
14              app: wordpress
15      ports:
16        - port: 3306

Kubernetesネットワークポリシーの適用

サンプルのYAML NetworkPolicyマニフェストが完成しました。次のようになります。

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: sample-network-policy
5  namespace: default
6spec:
7  podSelector:
8    matchLabels:
9      app: webapp
10  policyTypes:
11    - Egress
12    - Ingress
13  ingress:
14    - from:
15        - podSelector:
16            matchLabels:
17              app: webapp
18      ports:
19        - port: 443
20        - port: 80
21    - from:
22        - podSelector: {}
23    - from:
24        - ipBlock:
25            cidr: 172.16.0.0/16
26      ports:
27        - port: 443
28        - port: 80
29    - from:
30        - ipBlock:
31            cidr: 0.0.0.0/0
32      ports:
33        - port: 443
34        - port: 80
35  egress:
36    - to:
37        - namespaceSelector: {}
38          podSelector:
39            matchLabels:
40              k8s-app: kube-dns
41      ports:
42        - port: 53
43          protocol: UDP
44    - to:
45        - podSelector: {}
46    - to:
47        - podSelector:
48            matchLabels:
49              app: webapp
50      ports:
51        - port: 443
52        - port: 80

次に、このファイルをKubernetesクラスターに適用します。まず、ファイルをsample-network-policy.yamlとして保存します。

次に、他の多くのKubernetes設定と同様に、kubectlコマンドラインインターフェース（CLI）を使って定義ファイルを適用します。

次のコマンドを実行します。

1kubectl apply -f sample-network-policy.yaml

Kubernetesネットワークポリシーの検証と監視

従来型のファイアウォール管理と同様に、Kubernetesネットワークポリシーの検証と監視には運用上の監督が欠かせません。既存のネットワークルールが関連するワークロードに引き続き適用されるか、定期的に見直す必要があります。

また、トラフィックの問題をトラブルシューティングしたり、異なるネットワークポリシー間の競合を調査したりするために、ルールベースを検証する必要が生じることもあります。幸い、kubectl CLIを使ってNetworkPolicyを検証できます。次のコマンドを実行すると、現在のネットワークポリシーを分析・監視できます。

1kubectl describe networkpolicy <networkpolicy name as listed in the YAML manifest>

以下は、ingressポリシータイプの出力例です。

また、この画像はegressポリシータイプの出力例を示しています。

Kubernetesネットワークポリシーを適用する際のベストプラクティス

他のネットワークセキュリティ設定と同様に、Kubernetesネットワークポリシーでは、次のベストプラクティスに従いましょう。

• 明示的に許可した通信のみが行われるよう、デフォルトのdeny-allネットワークポリシーを使用する。

• 相互に通信する必要があるPodを、PodSelectorパラメーターを使ってグループ化する。

• ネームスペース間の通信は、必要な場合にのみ許可する。

• Kubernetesクラスター内であっても、不要なネットワーク通信は許可しない。

• クラスター内のPodが、クラスター外からのネットワークトラフィックを受信できるようにする場合は慎重に判断する。

• パブリックインターネットへの送信トラフィックを拒否すると、特定のアプリケーションの更新や検証プロセスに支障が出る場合があります。

Kubernetes CNIプラグインでネットワークポリシー管理を最適化

CNIプラグインの利点の1つは、Network Policyの実装の詳細を抽象化できることです。これにより、クラスター管理者は基盤技術の複雑さに煩わされることなく、ニーズに最適なソリューションを選択できます。

ただし、ディストリビューションやプロバイダーが追加していない限り、KubernetesのデフォルトインストールにはCNIプラグインがあらかじめ含まれていません。そのため、ニーズに合ったプラグインを選んでインストールする必要があります。また、ディストリビューションにデフォルトのプラグインが含まれていても、別のプラグインの方が要件に適している場合があります。

多数のCNIプロバイダーがあり、特に広く使われているものには次のようなものがあります。

• Cilium

• Calico

• Antrea

プラグインごとに独自の機能があるため、ネットワークとネットワークセキュリティの要件に最適なものを判断するには、いくつか試してみる必要があるかもしれません。

まとめ

複雑なルーティング、トラフィックルール、セキュリティインテグレーションを伴うエンタープライズネットワークトポロジーの設定には、手間がかかります。幸い、Kubernetes環境では、従来型インフラストラクチャでファイアウォールが担っていた役割をネットワークポリシーで実現できます。

もちろん、ネットワークポリシーの設定は、定期的な再評価とメンテナンスが必要なプロセスの第一歩にすぎません。組み込みのkubenetプラグインはポリシー管理に一定のネットワーク機能を提供しますが、他のCNIプラグインには、より高度な機能があります。適切なポリシーと管理方法を組み合わせることで、ネットワークトラフィックを安全かつ効率的に保つことができます。

Kubernetesセキュリティに関するその他のリソース

• Kubernetesセキュリティ：よくある問題とベストプラクティス

• KubernetesでDockerイメージをビルドする

• Kubernetesモニタリングガイド 2022

• 理解しておきたいKubernetes Security Contextの設定10選

• Kubernetesオペレーターがもたらすセキュリティ上の影響