Kubernetes NetworkPolicy で Pod のアウトバウンド通信を制御する – egress と CNI を分けて考える

Kubernetes の NetworkPolicy を使って、Pod からのアウトバウンド通信を制御する考え方を確認します。重要なのは、NetworkPolicy は Kubernetes の標準リソースですが、実際にパケットを制御するのは CNI 側であり、どこまで効くかは利用している CNI とクラスタ設計に依存するという点です。

NetworkPolicy でできること

NetworkPolicy は Pod に対する ingress / egress の通信制御を定義します。ただし、定義を書いただけで必ず効くわけではありません。Calico など NetworkPolicy を実装する CNI が必要です。

• podSelector で対象 Pod を選ぶ
• policyTypes で Ingress / Egress を指定する
• egress で宛先 IP、namespace、Pod、port などを許可する
• 一度 egress policy の対象になると、許可していない外向き通信は拒否される

RFC1918 宛てだけ許可する例

次は、対象 namespace の Pod から RFC1918 宛てだけを許可する例です。これは「内部ネットワークだけへ出す」考え方の例ですが、このままだと DNS への通信も許可されない場合があります。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-rfc1918-only
  namespace: my-system
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/8
        - ipBlock:
            cidr: 172.16.0.0/12
        - ipBlock:
            cidr: 192.168.0.0/16

このポリシーは、全 Pod を対象にした egress 制御です。実際の環境では、DNS、proxy、監視、ログ転送、イメージ取得など、許可すべき通信を個別に洗い出します。

DNS を許可する考え方

Pod が名前解決を必要とする場合、CoreDNS への UDP / TCP 53 を許可する必要があります。Kubernetes 標準の NetworkPolicy では、FQDN そのものを直接指定する制御は扱いにくいため、DNS を許可することと、名前解決後の宛先通信をどう制御するかは分けて考えます。

kubectl -n kube-system get svc kube-dns
kubectl -n kube-system get pod -l k8s-app=kube-dns -o wide

注意点

• DNS への通信を許可しないと名前解決できなくなる。
• proxy 経由で外へ出す場合は、proxy 宛ての通信を明示的に許可する。
• CNI が NetworkPolicy を実装していない場合、この定義は期待どおりに効かない。
• FQDN ベースの制御は Kubernetes 標準の NetworkPolicy だけでは扱いにくい。
• 外部通信の監査ログをどこで取るかは、NetworkPolicy だけでは解決しない。

NetworkPolicy は通信を絞るための部品です。インターネット向け通信を統制したい場合は、proxy、DNS、Firewall、CNI のログ、監査の仕組みと組み合わせて設計します。

確認

NetworkPolicy は適用しただけで満足せず、対象 Pod から許可した通信と拒否したい通信の両方を確認します。

kubectl -n my-system get networkpolicy
kubectl -n my-system describe networkpolicy allow-rfc1918-only
kubectl -n my-system run curl-test --rm -it --image=curlimages/curl -- sh
kubectl -n my-system get pod -o wide

確認用 Pod を使う場合は、その Pod が NetworkPolicy の対象 selector に含まれているかも確認します。対象外の Pod でテストすると、ポリシーが効いていないように見えることがあります。

まとめ

NetworkPolicy は Pod の通信範囲を狭めるための基本機能ですが、インターネット向け通信を実運用で制御する場合は、DNS、proxy、CNI の実装、監査ログを合わせて考える必要があります。

Kubernetes 標準の NetworkPolicy は、Pod と通信方向を宣言するための仕組みです。外部通信の統制全体を任せるものではありません。どの Pod が、どこへ、どの経路で、どのログを残して通信するのかを設計することが重要です。

関連する記事

次に進む

参考書籍

関連記事

Kubernetes に LoadBalancer はないのか – Service、MetalLB、CNI BGP を分けて考える Kubernetes Multus がうまく動かない時に考えること – CNI を複数持つ難しさ Kubernetes Multus の導入 – Pod に複数 NIC を接続する Kubernetes クラスター構築 – kubeadm で controlPlaneEndpoint と CNI を決める Kubernetes disk-pressure で Pod が起動しない場合 Kubernetes Nginx コンテナの実行 – Deployment で Pod を管理する MicroK8s で kube-ovn を有効化する – CNI を後から切り替える難しさ Kubernetes Calico eBPF の設計メモ – kube-proxy 代替、DualStack、高可用性をどう見るか