Efficient EKS Pod Communication: A Practical Implementation Using Cloudflare Zero Trust and CoreDNS

EKS Pod 通信を効率化: Cloudflare Zero Trust と CoreDNS による実践事例

Transcript

1. EKS Pod 通信を効率化: Cloudflare Zero Trust と CoreDNS による実践事例 Kubernetes Meetup Novice #39 石川 雲 / Kumo Ishikawa
2. 自己紹介 石川 雲（いしかわ くも） 横断 SRE 組織(SRG)所属 Platform Engineering / セキュリティ領域 担当 Kubestronaut (2025/6 から) 2/47
3. これまでの発表 3/47
4. 今回の発表内容 不採択( )の CfP から、Kubernetes 領域を絞った内容 (Ameba のみ) KeyWord: Kubernetes / CoreDNS / Cloudflare Zero Trust 4/47
5. 今回扱う課題 Cloudflare Zero Trust を活用して、次の 2 点を解決する 1. Pod の外向き公開の複雑さ Load Balancer のコストが高い 認証レイヤーをどこに置くか問題 2. Pod への内向き接続の面倒さ Port Forward の限界 マルチクラスタ・マルチクラウドアカウントをまたぐローカル開発 5/47
6. 記事版 もっと読みやすい記事版も書きました。是非ご覧ください。 6/47
7. 1. Pod の外向き公開の複雑さ 7/47
8. Pod の外向き公開手段 代表的な公開手段: Ingress Controller 経由 AWS / Google Cloud では、ALB / GCLB を使用 NGINX Ingress Controller (RIP) Gateway API 経由 (何もわかってない) Ingress Controller → Ingress Resource → Service → Pod 8/47
9. Pod の外向き公開手段 代表的な公開手段: Ingress Controller 経由 AWS / Google Cloud では、ALB / GCLB を使用 NGINX Ingress Controller (RIP) Gateway API 経由 (何もわかってない) AWS: Listener → Target Group → Target Group Binding → Service → Pod 9/47
10. 問題: Load Balancer のコストが高い インターネット公開する需要がある: 内部ツール、Dev/Stg の Application 多数のエンジニアが使う開発ツールもあれば、数人だけが使う管理ツールもある 気づいたら Load Balancer の台数がどんどん増えている 開発環境の一例 10/47
11. 問題: Load Balancer のコストが高い よくある対策 1. 複数の Listener Rule を 1 台の Load Balancer に集約する 2. NodePort で運用する 3. ALB を使わず、Port Forward 運用にする いずれも、開発生産性の低下につながる場合がある 11/47
12. 問題: 認証レイヤーをどこに置くか? 対象: Dev/Stg 環境の Application・内部ツール 悪い例: 認証を設定しない 認証を設定しない 12/47
13. 問題: 認証レイヤーをどこに置くか? 選択肢: 1. Application 自身の認証機能を使う 2. Load Balancer の Listener Rule に OIDC 認証を設定する 3. Ingress の後段に OAuth2 Proxy を配置する Application 自身の認証機能を使う 13/47
14. 問題: 認証レイヤーをどこに置くか? 選択肢: 1. Application 自身の認証機能を使う 2. Load Balancer の Listener Rule に OIDC 認証を設定する 3. Ingress の後段に OAuth2 Proxy を配置する Load Balancer の Listener Rule に OIDC 認証を設定する 14/47
15. 問題: 認証レイヤーをどこに置くか? 選択肢: 1. Application 自身の認証機能を使う 2. Load Balancer の Listener Rule に OIDC 認証を設定する 3. Ingress の後段に OAuth2 Proxy を配置する OAuth2 Proxy を Ingress の後段に配置する 15/47
16. 現実は上手く行かない 重要な背景: 開発用・内部用 Application の利用者には社外の人もいる → 関係者全員の IT リテラシーをカバーできる、「使ってもらいやすい」認証方法が必要 技術負債を抱えた Application も多く、認証のためのインフラ・コード改修が難しいケースもある Ameba の事例 (2024 年時点): 内部 / 開発用 Application の約 2 割は認証なし 認証が設定されている Application のうち、7 割以上が Basic Auth（社外共有しやすいため） 16/47
17. 2. Pod への内向き接続の面倒さ 17/47
18. Pod への内向き接続手段 対象: Dev/Stg 環境の Application・内部ツール Debug Pod + Debug Image Kubernetes クラスタ内でのデバッグ 専用の Debug イメージを用意する必要がある Pod Port Forward 内部ツール・管理ツールの一時的な利用 ローカル開発 18/47
19. 問題: Port Forward の限界 Terminal セッションが切れるとき ローカル開発・デバッグ中にセッションが切れると、毎回 Port Forward を張り直す必要がある 複数の Pod に対して Port Forward を行うとき 複数の Terminal セッションを維持し、それぞれの Pod に対して Port Forward を行う k9s/lens などの GUI ツールを使う 同じポート番号を使う場合、ポートの割り当てを工夫して管理する必要がある 19/47
20. 問題: マルチクラスタ等をまたぐローカル開発 複数クラスタ・マルチクラウドアカウントをまたいで作業するとき 複数の Terminal セッションを維持し、それぞれの Cloud Credential と context で Port Forward を行う必要がある 同じセッション内で context を切り替えなければ、既存の Port Forward は切れないが、運用が煩雑 同じポート番号を使う場合、ポートの割り当てを工夫して管理する必要がある 複数Terminalを使う例 20/47
21. Cloudflare Zero Trust による解決策 21/47
22. 解決策の概要 Cloudflare Zero Trust の機能群と Kubernetes を組み合わせて、次のように解決 1. Pod の外向き公開の複雑さ Cloudflare Access Policy で認証・認可を担保し、Cloudflare Access Application + Tunnel で Pod のインターネット公開を実現 2. Pod への内向き接続の面倒さ Cloudflare Access Policy + WARP で認証・認可を担保し、Virtual Network でマルチクラスタ・ マルチクラウドアカウントを集約し、 Resolver Policy + CoreDNS で Kubernetes Service Discovery をローカル PC でも可能にする 22/47
23. Cloudflare Zero Trust とは 主要な機能群: 1. Cloudflare Access DNS Proxy ベースの認証・認可 2. Cloudflare Gateway Tunnel + Gateway Policy による VPN 的機能 23/47
24. Cloudflare Zero Trust とは その他 WARP: Tunnel先のPrivateリソースに接続する端末クライアント Resolver Policy: DNS 条件分岐 料金 50 ユーザーまで無料 小規模の開発に最適 24/47
25. Pod の外向き公開の複雑さの解決 25/47
26. 理想 Podを公開するための経路設定・証明書・認証・DNSなどを全部一括で設定できる 26/47
27. Access を使用した Pod 公開 Cloudflare Access Application + Tunnel を使ったインターネット公開 Cloudflare Access + Tunnelの全体像 27/47
28. Access を使用した Pod 公開 Argo Workflow Pod 公開の事例 認証画面はCloudflare Accessで一括管理 28/47
29. 設計のポイント Cloudflare 内では、HTTPS 通信が保証されている Tunnel → Pod が HTTPS 通信になっている場合は要注意 cloudflared を、対象 Pod に到達可能なネットワークに配置する cloudflared に Network Policy を設定することで、複数レイヤのネットワーク制御が可能 Tunnel のドメインはデフォルトで 認証なし Tunnel 上で対象 Pod への通信を開けると、 cfargotunnel.com の DNS Record が作成される この DNS Record に Access Policy を設定するまでは、誰でもアクセス可能 29/47
30. すべての操作は IaC で管理可能 1. Cloudflare Tunnel (cloudflared connector) の配置 (Helm) 2. SubDomain の登録 (Terraform) 3. Service の Tunnel 経由での公開 (Terraform) 4. Access Application と Access Policy の設定 (Terraform) 30/47
31. ALB と Cloudflare 方式の比較 観点 ALB Cloudflare コスト 各 App で LB 必要 LB 不要,50 人まで無料 認証 前段配置必須 Access で一元管理 設定 各レイヤーで IaC Cloudflare 関連 Iac 証明書/DNS 運用 ACM+Route53 Cloudflare DNS まとめ Load Balancer のコストが高い → 「Access + Tunnel を活用し、LB をなくす」ことで解決 認証レイヤーをどこに置く問題 → 「Access Policy を Access Application に紐づけて一括管理」す ることで解決 31/47
32. Pod への内向き接続の面倒さの解決 32/47
33. 理想 ローカル環境を Kubernetes 内部ネットワークのように扱える (Port Forward なしで Pod に接続できる) 33/47
34. Port Forward なしで Pod に接続するための必須条件 1. ローカルから Pod / Service の IP へ直接到達できること 2. IP は常に変わるため、Pod / Service に対して FQDN で DNS Query が投げられる こと この 2 点が満たされれば、次のように自在に Pod / Service にアクセスできるようになる 34/47
35. 条件 1: Pod / Service IP への到達 35/47
36. 条件 1: Pod / Service IP への到達 Cloudflare Tunnel + WARP を利用 Pod IP 直接アクセスの例 補足: AWS では Pod IP は VPC Subnet に属する一方、Service IP はデフォルト VPC 外の仮想レンジの ため、WARP からは Service IP に直接到達できない Pod へ直接アクセスしたい場合は、Headless Service を利用する必要がある 36/47
37. 条件 2: Service FQDN の名前解決 37/47
38. Kubernetes Service Discovery の復習 svc-name.namespace.svc.cluster.local の DNS Query を CoreDNS Pod に投げ ることで、Service IP を取得できる つまり、CoreDNS Pod へ自由にアクセスで きれば、Service IP も自由に取得できる 38/47
39. 条件 2: Service FQDN の名前解決 Step A: CoreDNS の固定 IP 化 CoreDNS Service として Internal Network Load Balancer を作成 (AWS の場合) Network Load Balancer に固定の Private IP を割り当てる CoreDNS Service (`kube-dns-nlb` という名前) を新設 39/47
40. 条件 2: Service FQDN の名前解決 Step B: Resolver Policy を使った DNS 経路 WARP の Split Tunnel 設定で、 *.svc.cluster.local のトラフィックを Cloudflare Edge へ送信 Resolver Policy で、 *.svc.cluster.local の DNS Query を CoreDNS NLB の IP へ転送 `stg-blog-xxx.svc.cluster.local(10.106.8.140)`は、127.0.2.2(Local DNS Proxy) に向けられる 40/47
41. 条件 2: Service FQDN の名前解決 41/47
42. 理想(もう一つ) 担当プロダクトの全開発リソースを一つのTerminalセッションでアクセスできる 42/47
43. マルチクラスタ・マルチクラウドアカウント Virtual Network を活用するし、複数のクラスタ・クラウドアカウントにある Tunnel を統合 全プロダクトの Route と Tunnel を一つの区切りで管理し、認証方法を設定 WARP を ON にするだけで、すべてのクラスタ / クラウドアカウント上の Private IP にアクセス可能 本番リソースを別 Virtual Network にすることで、開発リソースと本番リソースを分離 43/47
44. 複数クラスタでの Service FQDN 重複 <app-name>.<namespace>.svc.cluster.local が、どのクラスタでも同じ名前の場合: クラスタ / 環境名つき FQDN を付与する: <env-name>-<app-name>.<namespace>.svc.cluster.local stg-app-name.namespace.svc.cluster.local 、 prd-app-name.namespace.svc.cluster.local Resolver Policy で、環境名つき FQDN の正規表現ルールを設定する Terraform 設定例 44/47
45. Port Forward と Cloudflare 方式の比較 観点 Port Forward Cloudflare 継続性 切れやすい 安定 マルチ環境 context 切替が必要 FQDN で直接アクセス UX ポート貼り直し・手作業が多い WARP の On / Off だけで OK まとめ Port Forward の限界 → WARP + Tunnel を使って、ローカルから直接 Pod / Service にアクセス できる」ことで解決 マルチクラスタ・マルチクラウドアカウントをまたぐローカル開発 → Virtual Network + Resolver Policy + CoreDNS で解決 45/47
46. まとめ Cloudflare Zero Trust を活用することで、Kubernetes を用いたローカル開発における 課題を解決する手法を紹介した 1. 外向き公開の複雑さを解消: Access + Tunnel → 認証・証明書・DNS・公開経路を Cloudflare に集約し、外向き公開の複雑さを解消 → LB コストを抑えつつ、環境ごとの公開を安全に実現 2. 内向き接続の面倒さを解消: Tunnel + Resolver Policy + CoreDNS → Private 接続を FQDN ベースに統一し、Port Forward 運用から脱却 → マルチクラスタ / マルチアカウントをまたぐローカル開発をシンプルにする 低コスト・低リスクなので、ぜひ Cloudflare Zero Trust を試してみてください 46/47
47. ありがとうございました 47/47