KubernetesのNetworkPolicyで「全拒否」と「全許可」を設定する方法

toshi

2026年4月12日 10:57

kubernetesでPod同士の通信を制御したい場面って、意外とありますよね。

AWSだとEC2同士の通信はSecurity Groupでコントロールできますが、
kubernetesでPod間の通信を制御したい場合に出てくるのがNetworkPolicyです。

実際に触っている中で、「これちょっと分かりづらいな」と感じたポイントがありました。
それが「全拒否」と「全許可」の書き方です。

ingress: [] が全拒否、
ingress: [{}] が全許可。

ぱっと見はほとんど同じなのに、動きは真逆です。
ちょっとした違いなのに結果が大きく変わるので、ここは一度整理しておきたいところです。

(1) 全拒否を設定する方法（ingress: []）

例えば、以下のようなNetworkPolicyがあるとします。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nginx-deny-all-ingress
  namespace: network-test
spec:
  podSelector:
    matchLabels:
      app: nginx
  policyTypes:
  - Ingress
  ingress: []     # 全拒否

この中にある ingress: [] がポイントです。

これは許可ルールが1つもない状態を表しています。

NetworkPolicyは「許可された通信だけを通す仕組み」なので、
許可が存在しない場合は、すべて拒否されます。

たとえるなら、入館リストを用意したのに中身が空の状態です。
リスト自体はあるのに、誰も名前が書かれていないので、結果として全員入れません。

そのため、この設定を適用すると対象のPodは外部からの通信を受け付けなくなります。

(2) 全許可を設定する方法（ingress: [{}]）

今度は全許可のパターンです。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nginx-allow-all-ingress
  namespace: network-test
spec:
  podSelector:
    matchLabels:
      app: nginx
  policyTypes:
  - Ingress
  ingress:
    - {}

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nginx-allow-all-ingress
  namespace: network-test
spec:
  podSelector:
    matchLabels:
      app: nginx
  policyTypes:
  - Ingress
  ingress: [{}]

こちらは条件なしの許可ルールが1つある状態です。

{} は送信元やポートの条件を指定していないため、
どこからでも、どのポートでも通信を受け入れる形になります。

イメージとしては、入館ルールに「条件なしで通してよい」と1行書かれている状態です。
細かい制限がないぶん、結果として全員通れるようになります。

デバッグや疎通確認のときに使われることが多い設定です。

ドキュメントなどでは - {} の形式で書かれていることが多いですが、
自分は全拒否との対比を分かりやすくするために ingress: [{}] と書くことがあります。

ingress: [] と並べたときに、空なのかルールがあるのかが判断しやすくなるためです。

(3) 似ているのに結果が逆になる理由

この2つの違いは「ルールが存在するかどうか」です。

ingress: []
ルールはあるが中身が空
そのため許可される通信はない
ingress: [{}]
条件なしのルールが1つある
そのためすべての通信が許可される

同じように見えても、
片方は「何も許可していない」、もう片方は「条件なしで許可している」という違いがあります。

ここを取り違えると、意図しない通信状態になるので注意が必要です。

(4) よくある勘違い

(1) NetworkPolicyが存在しない場合

制御自体がない状態なので、基本的には通信できます。

(2) NetworkPolicyが存在して ingress: [] の場合

対象のPodは外部からの通信を受け付けなくなります。

「書いていない」と「空で書いている」は意味が違う、という点がポイントです。

(5) 実務での使い分け

(1) まず全部閉じたい場合

ingress: []

不要な通信を先に止めて、必要なものだけ後から許可していく形です。

(2) 一時的に全部開けたい場合

ingress:
  - {}

ingress: [{}]

疎通確認やデバッグ時に、一時的に通信を通したい場合に使われます。

(6) サンプルで実際に確認してみる

実際に試すと、この違いはかなりはっきり体感できます。

以下では、curl が入っているPodから nginx に通信できるかどうかを確認します。

まずは次のマニフェストを apply します。

apiVersion: v1
kind: Pod
metadata:
  name: curl
  namespace: network-test
  labels:
    app: curl
spec:
  containers:
    - name: curl
      image: curlimages/curl:latest
      command: ["sleep", "infinity"]
  restartPolicy: Always
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: network-test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          ports:
            - containerPort: 80
          securityContext:
            capabilities:
              add: ["NET_ADMIN"]
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: network-test
spec:
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nginx-deny-all-ingress
  namespace: network-test
spec:
  podSelector:
    matchLabels:
      app: nginx
  policyTypes:
  - Ingress
  ingress: []     # 全拒否
  # ingress: [{}] # 全許可

apply したあと、以下のコマンドで確認できます。

kubectl exec -n network-test curl -- curl -v http://nginx.network-test.svc.cluster.local:80

ingress: [] の状態では通信できず、
ingress: [{}] に変更すると通信できるようになります。

見た目は少ししか違わないのに、結果がはっきり変わるので、この差は体感しておくと記憶に残りやすいでぜひ試してみてください

まとめ

KubernetesのNetworkPolicyで全拒否と全許可を設定する場合、ingress の書き方がそのまま挙動に直結します。

ingress: [] は許可ルールがないため全拒否、
ingress: [{}] は条件なしの許可ルールがあるため全許可になります。

Yamlの配列の書き方、なんとなく苦手なんですよね…
NetworkPolicyで配列が出てくると、一瞬思考が止まってしまうことがあります