要約

  • Kubernetes は NetworkPolicy を、選択された Pod の望ましい振る舞いとして説明する。ingress と egress の規則は加算的であり、Pod 間接続には送信元の egress と宛先の ingress の双方の許可が必要である。
  • 同じ文書は推論の限界も示す。実装するネットワークコントローラがなければリソースは効果を持たず、処理は最終的に行われるが API から時点は分からず、既存接続への影響は実装依存である。
  • 一つのフローについて述べるには、ポリシー改訂、selector と endpoint の状態、ネットワーク実装、時刻を限定した接続観測、そして独立した ID・アプリケーション判断の記録を分けて残す必要がある。

「default deny」という言葉は YAML をすでに成立したセキュリティ結果のように見せやすい。そうではない。NetworkPolicy の価値は宣言的な制御面にある。選択された Pod を ingress、egress、または両方について隔離し、なお許される接続を記述できる。これは望ましいネットワーク境界についての決定である。特定の接続が拒否されたこと、許可された接続が確立したこと、ある workload が安全になったことの証拠ではない。

リソースモデルが最初の境界を引く。NetworkPolicySpec が表すのは desired behavior である。ポリシーは Pod を選び、Ingress または Egress の isolation を示し、規則を置く。効果は順番に上書きされる拒否ではなく加算的である。Pod がある方向で隔離されると、許される集合は適用ポリシーすべてが許す集合の和になる。送信元 Pod から宛先 Pod への接続には、送信元 egress と宛先 ingress の両方が必要である。この規則はポリシー集合を説明するが、実際に観測されたアドレス、port、protocol、時刻、process、packet path、接続結果を示さない。

selector の状態も別の事実である。podSelector、namespaceSelector、ipBlock は固定された具体的 endpoint の一覧ではない。label は変わり、Pod は置き換わり、Service の endpoint や経路も変化する。Kubernetes は ingress/egress 機構がアドレスを書き換える場合があると注意する。その場合、書き換えが NetworkPolicy 処理の前か後かは定義されず、network plugin、cloud provider、Service 実装、またはその組合せで動作が異なり得る。manifest は想定範囲を示せても、観測済み packet が実行点でどのように表現されたかを裁定しない。

実装層はさらに別の証拠面である。Kubernetes は NetworkPolicy を network plugin が実装すると説明する。実装する controller なしにリソースを作っても、API が存在したままで効果はない。これは製品や管理者への非難ではない。API server が object を受理したことは control plane の事実にすぎず、data plane component の capability、configuration、health、実際の稼働を示すものではない。

時間は結論をさらに限定する。Kubernetes は作成された NetworkPolicy が最終的には network plugin に扱われるとするが、API にいつ完了したかを示す方法はない。Pod や policy が変化するとき、分散した実装が一時的に少し不整合な view を持ち得るとも説明する。policy 集合の変更が既存接続へ及ぼす効果は実装定義である。これは例外ではなく、configuration snapshot に保存していない runtime history を語らせない理由である。

protocol の範囲にも限界がある。NetworkPolicy は layer 4 の TCP、UDP、そして任意対応の SCTP 接続に対して定義される。他の protocol の振る舞いは plugin により異なり得る。見かけ上の境界を、すべての packet、hostNetwork path、service mesh、暗号化、workload identity、authentication、DNS、application authorization、delivery の一般的な主張に変えてはならない。それぞれ別の control surface であり、別の証拠が要る。

Daniel Kade は重要な場面のために五部構成の flow receipt を提案する。第一に policy revision: namespace、policy identifier、generation または immutable capture、selector、direction、rule、観測時刻。第二に selector と endpoint の状態: 関係する Pod と Namespace の label、IP または endpoint mapping、読取時刻。第三に network implementation: 宣言された NetworkPolicy capability、version、関連 configuration、health evidence。第四に時刻を限定した connection observation: 観測された source と destination、protocol、port、direction、result、collector、可視性の限界。第五に workload identity、authorization、TLS、DNS、application response、deployment についての独立記録である。機微な詳細を保護しても、記録を混同する必要はない。

この方法は通常の結果も正直に説明する。policy が正しくても別の data-plane fault が接続を妨げることがある。双方の方向で許された flow でも DNS、TLS、authentication、application で失敗し得る。policy は API に受理されても、特定 plugin が有効化するのは後かもしれない。どれも欠陥や incident を意味しない。一つの manifest に network flow の全履歴を背負わせるべきではない理由を示すだけである。

情報源

  1. Kubernetes — Network Policies
  2. Kubernetes — Services, Load Balancing, and Networking
  3. Kubernetes API リファレンス — NetworkPolicy v1