AdminNetworkPolicy への期待が募る

はじめに

• 本投稿は、Kubecon&CloudNativeCon@NA2023 の NetworkPolicy に関する以下の発表を要約し、適宜捕捉した記事です。添付しているスクリーンショットは全て発表スライドから引用しています。
  • Network Policy API: Intro and Project Update （こちらの発表は NetworkPolicy の開発・実装を行っている NetworkPolicy SIG の直近の動向やメンバを募る内容になっていました。）
  • 「AdminNetworkPolicy: A New Kubernetes-Native API for Comprehensive Cluster-Wide Network Security」 （こちらの発表はハリー・ポッターの世界観に沿って NetworkPolicy が解説されていて非常に分かりやすいです。）
• NetworkPolicy とは、kubernetes（以降、k8s）クラスタ上の通信を制限できるリソースのことで、k8s におけるセキュリティを担保するために重要な役割を果たします。但し、後述するような Issues があることから様々なユースケースを補完するためのリソースである AdminNetworkPolicy の開発が進められています。
  • 従来は Calico Network Policy や Cilium Network Policy といったカスタムリソースを導入することで標準リソースのみでは対応できないユースケースを満たす動きがありましたが、それを標準リソース化する試みと言って良さそうです。

NetworkPolicy v1 とは

NetworkPolicy v1 の概要

• 2016 年に最初にリリースされた標準の NetworkPolicy で現在もメンテナンスされているものです。たとえば以下のようなユースケースで使用できます。
  • 2 つのチームが 1 つの k8s クラスタ上でアプリケーションを開発・運用していた場合に、チーム内のリソース間のみが通信できるように設定する
    
  • Web3 層構造の各層に応じた通信制限を行い、フロントエンドはバックエンドにだけ、バックエンドは DB にだけ通信できるように設定する
    

NetworkPolicy v1 の Issues

• これに対して、以下のような Issues があります。
  • ホワイトリスト形式のルールしか定義できない（ホワイトリストに登録されていない通信は暗黙的に拒否される）ので、意図せず通信エラーが起き混乱を招きうる
  • 通信を拒否したり、Namespace に跨るポリシーの定義方法、それからポリシーの優先度付けなどといった仕組みがないことで管理者向けの機能がない
  • クラスタ内の通信の制限しか出来ないので、クラスタ外との通信を制限できない
• リリース当時はまだ管理者と開発者は同一人物が担うことが多く、あえて RBAC 等でユーザによって出来ることを制限するようなニーズがなかったため、管理者向けの機能は後回しになっていた、というのが実情だそうです。

AdminNetworkPolicy とは

AdminNetworkPolicy の目指すところ

• ニーズ探索をしたところマルチテナンシーを実現する機能に対する声が大きいことから、クラスタ管理者に対して Namespace 管理者というペルソナを想定した上で、テナントという概念が導入されています。複数の Namepsace をテナントに属させることで管理対象をグルーピングできるようにする狙いがあります。たとえばある Namespace 管理者が、管理している複数の Namespace 間の通信のみを許可するようなポリシーを記述する際には、テナント単位で指定できるようになるため管理負荷が削減されることでしょう。
• 一方で、Namespace 管理者が許可していない通信だとしても必ず通さないといけないものがあります。たとえば、DNS に対する ingress 通信やモニタリング関連の Pod からの egress 通信といったものがあるでしょう。クラスタ管理者が AdminNetworkPolicy を適用することで、こういった通信を特例で許可ないし拒否させるといったことを想定しています。
• また、クラスタ管理者が Namespace 管理者に対して判断する権限を委譲するようなユースケースも想定しています。
• 更には、Namespace 管理者が適切なポリシーを作成・適用しないことによる弊害を考慮し、管理者が明示的な BaselineAdminNetworkPolicy を適用することによってデフォルトのセキュリティ設定を施すこともゴールとして設定されています。仮に Namespace 管理者がポリシーを記述していなかったとしても最低限の制限が適用され、ゼロトラストを実現することができるようにです。

AdminNetworkPolicy の現状

• 1 年以上 v1alpha1 で、beta API に昇格できるように今も実装中ですが、次のようなデモがありました。
  • AdminNetworkPolicy による、Namespace 管理者が記述したポリシーのオーバーライド
    
  • クラスタ管理者による、Namespace 管理者に対する権限の移譲
    
  • Namespace 管理者が委譲されている通信に対してポリシーを設定していなかった場合の、デフォルトポリシー適用
    
• まとめると、次のようにクラスタ管理者が AdminNetworkPolicy と BaselineNetworkPolicy を、Namespace 管理者が従来の NetworkPolicy v1 を使うというのが現状実現できる構成のようです。
  
  たとえばテナントの話はデモに登場しなかったため、これから実装する範囲みたいです。これから説明する NPEP にもなっています。

NPEPs

NPEP とは

• NetworkPolicy を発展させる上で、本家 Kubernetes Enhancement Proposals（KEPs） に倣い Network Policy Enhancement Proposals（NPEPs） というものが管理されています。
• アジャイル開発におけるバックログのようなものだと思いますので、今後どういった機能が追加されそうか、どういった議論がなされたかなどがまとまっているということです。いくつか抜粋します。

NPEP 137（適合性プロファイル）

• NetworkPolicy のメンテナンスにおいて、正確で適切なフィードバックを受けられるように適合性プロファイルというものを追加することを検討しているそうです。これによって、どんな NetworkPolicy を適用した環境下で、どんなテストを実行し、どんな結果を得たのかが分かるようになり、何を目指して実装が進んだのかが分かりやすくなると考えているようです。
  

NPEP 126（クラスタ外との通信制御）

• 現時点の実装で Namespace と Pod を指定して egress 通信を制限できるようになっているが、今後は CIDR とノードも指定できるようにしたいと考えているそうです。
  • 但し、CIDR を指定したときにクラスタ内の仮想 IP アドレスも制限の範囲内に含めるべきかどうかについて等、議論がなされているという状況です。
    

NPEP 122（テナント）

• 先述していたようにテナントという概念を導入しようとしていますが、k8s 利用者が分かりやすく通信制限を実現することが究極的な目的なので、意見を広く公募しているという状況のようです。
  

Cyclonus

• こちらは NPEPs ではないのですが開発中であることが宣伝されていました。
• どこからどこへの通信が行われたか、行われなかった場合それが NetworkPolicy の問題なのかそれ以外の問題なのか、そういった疑問に対して認知しやすくなるような開発者ツールを開発しているそうです。
  • こういったツールを開発しつつ、AdminNetworkPolicy の実装にも役立てていくという方針のようです。

Network Policy v2

Network Policy v2 とは

• 元々 NetworkPolicy v1 にあった色々な課題を全部解決するものとして、NetowrkPolicy v2 を作ろうという話があったが、v1 と後方互換性があるように管理者向けの機能などを実現するのは無理があったということで、とん挫したらしいです。

DeveloperNetworkPolicy の可能性

• 現状は、AdminNetworkPolicy と BaselineNetworkPolicy 、それから従来の NetworkPolicy v1 を使うという構成ですが、NetworkPolicy v1 には暗黙的に拒否されるので混乱を生む、といった Issues が残ったままです。
• そのため、NetworkPolicy v1 に代わるものとして DeveloperNetworkPolicy を作っていけばよいのではないかという議論が始まっています。

Get Involved

• 良い NetworkPolicy を作るためには色々な人の声を聞き、満足の行くものを作っていく必要があるが、声も実装メンバも足りていないという状況なので、SIG 新規参画者向けにオンボーディングマップを定義してみた、とのことです。
  • Level 1
    • k8s contributer guide を読む
    • NetworkPolicy v1 ドキュメンテーションを読む
    • AdminNetworkPolicy の KEP を読む
  • Level 2
    • NetworkPolicy SIG のドキュメンテーションを読み、 Issue を発行する
    • Issue に対する help wanted がないかや、見本となる good first issueを読む
    • オープンなプルリクエストをレビューする
  • Level 3
    • NPEPs のプロセスを読む
    • 新しい NPEP を Issue と共に作成する

おわりに

• 私は 4 年前くらいに、マルチテナント環境を想定して、クラスタ管理者による NetworkPolicy の管理を Calico（Global）NetworkPolicy で実現できないか検証していたことがあります。標準リソースとカスタムリソースのどちらも、ハイフンやインデント一つの有無で全く異なる挙動をするので、検証するにしても前提が間違っていたことが後で判明するなど、なかなかテストが難しいと感じていました。
• そのため今回の NetworkPolicy SIG の開発事情を聞いて、個人的に一番良いなと思ったのは実は Cyclonus で、ネットワーク周りの設定をテストする際に活躍するようなツールになってくれると有難いなと思いました。