「Oracle Cloud Hangout Cafe (OCHaCafe)」ダイジェスト2 第3回

NetworkPolicyとPod間セキュリティ

最後に、CNIプラグインと密接な関わりがあるNetworkPolicyについて紹介します。

NetworkPolicy

Kubernetesでは、コンテナアプリケーション間の全ての通信を受信/送信ともにデフォルトで許可します。そこで、コンテナアプリケーション間の通信を制限するための仕組みが必要になりますが、その仕組みの1つがNetworkPolicyです。

NetworkPolicyとは、Pod間の通信を制限するファイアウォールのような機能のことで、レイヤー3/4で機能します。NetworkPolicyはNamespace/Podに付与するlabelや送信元/送信先IPアドレス・ポートを利用して通信を制御でき、許可ルールのみが定義できます。また、許可ルールとして定義したトラフィック以外は拒否するという挙動になります。なお、NetworkPolicyを利用するためには、対応しているCNIプラグインのインストールが必要です。

NetworkPolicyのリソースはNamespaceごとに作成し、適用範囲もNamespaceになります。複数のポリシーが存在する場合は、適用されているルールの和集合で適用されます。

networkpolicy

NetworkPolicyの設定項目

NetworkPolicyで設定できる項目を以下に整理します。

設定項目	内容
ポリシーの方向	Ingress/Egress/両方
設定対象のPod	セレクタで定義。省略した場合はNamespace内の全てのPodを対象
許可するIPアドレス(CIDR形式)	CIDRで指定。CIDR範囲内のIPアドレスを除外することもできる
許可するNamespace	セレクタで指定。省略した場合は全てのNamespaceを対象
許可するPod	セレクタで指定。省略した場合は全てのPodを対象
許可するポート	ポート番号とプロトコルを指定。省略した場合は全てのポートを対象

これを踏まえて、以下にNetworkPolicyの例を示します。

np-yaml

このNetworkPolicyによって実現される環境は下図のイメージになります。この図に示しているトラフィック以外は全て拒否されます。

np-image

ここで、NetworkPolicyのManifestを書く際の注意点について補足します。注意すべき点はnamespaceSelectorとpodSelectorです。Ingress/Egressともに、namespaceSelectorとpodSelectorはOR条件とAND条件の双方を定義できます。

例えば、AND条件として以下の例を見てみます。

np-careful1

この例では「app:helidonラベルの付いたNamespace内のrole:frontendラベルが付いたPodからの接続を許可」というルールになります。

一方で、OR条件として以下の例を見てみます。

np-careful2

この例では「app:helidonラベルの付いたNamespace内の全てのPodからの接続、または任意のNamespace内にあるrole:frontendラベルが付いたPodからの接続を許可」というルールになります。

この2つのManifestの違いは「podSelectorに-を付与する/しない」の差です。この差によってOR条件かAND条件かが決定されますが、このわずかな違いで許可ルールの意味合いが大分変わります。

NetworkPolicyのManifestを書く際には十分注意しましょう。

NetworkPolicyのメリットと注意点

ここまでの内容を踏まえて、NetworkPolicyのメリットと注意点をまとめておきます。

NetworkPolicyは、デフォルトで全ての通信が許可されているコンテナアプリケーション間通信に制限をかけるためのレイヤ3/4のネットワークセキュリティです。つまりはファイアウォールに相当する機能になります。NetworkPolicyを利用することによりコンテナアプリケーション間の通信をよりセキュアにでき、最低限のネットワークセキュリティを担保できます。

しかし、NetworkPolicyだけでは十分ではありません。NetworkPolicyはあくまでもネットワークセキュリティの出発点に過ぎません。例えば、HTTP/HTTPS/gRPCなどのレイヤ7レベルの制御や脅威検出はNetworkPolicyだとカバーできません。

コンテナアプリケーションの保護は、他にも以下の通り様々な種類があります。

RBAC認可
Pod Security Standards(PSS)/OPA(Open Policy Agent)
TLS Mutual 認証/IstioなどのService Mesh(レイヤ7レベルの制御)

これらのうち、一部は既に本連載で紹介していますので、併せて参照ください。

【Oracle Cloud Hangout Cafe Season5 #3「Kubernetes のセキュリティ」(2022年3月9日開催)】
【Oracle Cloud Hangout Cafe Season6 #1「Service Mesh がっつり入門!」(2022年9月7日開催)】

NetworkPolicyのユースケース例

最後に、NetworkPolicyのユースケース例を簡単に紹介します。

・ユースケース例: コンテナアプリケーション間で受信できるポート番号を制御
この例では、2つのコンテナアプリケーションについてrole:monitoringという監視用コンテナが受信できるトラフィックを5000番ポートのみに制限しています。これにより、監視用コンテナに対する余計なトラフィックの受信や意図しない通信を防ぐことができます。

np-example1

NetworkPolicyのデモ

当日のセッションでは、Kubernetes上にWordPressをデプロイし、Pod間のアクセスを制御しています。WordPressからMySQLへのコンテナ間の通信をNetworkPolicyによって3306ポートのみに限定し、セキュアなWordPress環境を構築しています。

また、デモの中ではCiliumが提供するNetworkPolicy Editorも利用しています。このエディタでは、NetworkPolicyがどのようなルールになるのかを可視化できます。当日のデモについては[動画リンク]を参照ください。

demo

CNI 2.0

当日のセッションでは「KubeCon + CloudNativeCon Europe 2021」のセッション“Towards CNI v2.0” - Casey Callendrello, Red Hatで触れています。これは現状のCNIをv1.0とし、以下のような課題を挙げています。

プラグイン(バイナリ)のセキュリティリスク
CNIプラグインのConfigurationを定義しなければならないことによる様々なトラブル

これらを克服するためにCNI v2.0という仕様策定を進めるという内容です。2024/2現在でCNI v2.0の開発に関する目立った情報はありませんが、今後の開発が期待されます。

おわりに

今回は、Dockerのネットワークから始まり、Kubernetesのネットワークモデルやネットワークモデルを実現するCNIプラグイン、CNIプラグインの重要な機能の1つであるNetworkPolicyについて紹介しました。マネージドKubernetesでも自前のKubernetesでも、ネットワーク周りの仕組みや理解は非常に重要です。

本記事がKubernetesのネットワークの理解の第一歩になれば幸いです。