EKSでZeroTrustNetworkに対応するためにやったこと

EKSでゼロトラストネットワークに 対応するためにやったこと JAWS-UG横浜 #103 - SRE支部コラボLT会 2026.9.18 J B C C 株 式 会 社 Te c h n i c a l E x p e r t 新居田 晃史

自己紹介 • 新居田 晃史（にいだ あきふみ） • 所属 – JBCC株式会社 カスタマーイノベーションラボ - Technical Expert • 日本最速ITエンジニア – • 2010-2020 （※週刊BCN編集部調べ） フルマラソン 2:29:56 X @nid777 Facebook Akifumi Niida コミュニティ活動 – JAWS DAYS 2025 実行委員長 – – AWS Samurai 2024 JAWS-UG 横浜支部 – AWS Community Builder （Container） – – – Cloudflare Meetup ChatGPT Meetup Tokyo AIコーディング道場 2

背景 • 社内で安全に利用できるAIエージェント環境を構築 • Dify Enterprise (EKSで運用) を採用し、AWS上にデプロイ • 社内のセキュリティポリシーに準ずる形にする必要がある – ゼロトラストネットワークを採用しており、対応が必要となった ・・・その戦いの学びの共有です（AI基盤をネットワークレベルのObservabilityに対応した 話） VPC VPC 変更前 EKS Pod / ノード 変更後 0.0.0.0/0 NAT Gateway 公開 CA EKS Pod / ノード 0.0.0.0/0 VGW VPN → Prisma SSL Forward Proxy Prisma CA デフォルトルートの変更で、外向きHTTPSが復号経路に入る

１ ． AW S A P I へ の アク セ ス は V P C 内 通 信 に す る VPCエンドポイントで復号経路を外し、 CAを組み込む要素を減らす VPC：10.0.0.0/16 VPC リゾルバ ＋ private DNS sts.ap-northeast-1.amazonaws.com → 10.0.1.23 名前解決 PrivateLink HTTPS：TCP 443 Pod（IRSA） 10.0.0.0/16 → local Interface エンドポイント ENI：10.0.1.23 SG：TCP 443 VPCの以下の機能を有効化することで、リクエスト先がVPC内のアドレスとなる • Enable DNS hostnames • Enable DNS support https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/privatelink-access-aws-services.html AWS STS

• https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/privatelink-access-aws-services.html

VPCエンドポイントの挙動 InterfaceとS3 Gatewayの違い Interface STS / EC2 など Gateway 宛先 IP ルート Endpoint 10.0.1.23 10.0.0.0/16 → local ENI S3 のパブリック IP S3 prefix list → vpce-… S3 Gateway S3 どちらも、結果的に0.0.0.0/0を使わないが、アクセス先の違いを理解しておく必要はある https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/interface-endpoints.html https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/gateway-endpoints.html

• https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/interface-endpoints.html
• https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/gateway-endpoints.html

Prisma Access 経由にしたもの / しなかったもの AWS APIで対応しなかったもの。(Route53, AWS WAFv2, ACM) VPC Endpoint VGW → Prisma AWS API AWS API sts / ec2 / elasticloadbalancing external-dns → Route 53 elasticfilesystem / logs / autoscaling ALB Controller → WAFv2 / ACM LLM 外部 LLM bedrock / bedrock-runtime LiteLLM → Azure OpenAI / Vertex AI bedrock-agent-runtime Vertex の WIF → sts.googleapis.com 既設・イメージ取得 SaaS / Plugin secretsmanager / ecr.api / ecr.dkr 実行 Pod / plugin-connector / sandbox S3 Gateway（レイヤ本体） 外部 SaaS・Marketplace など https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/aws-services-privatelink-support.html

• https://docs.aws.amazon.com/ja_jp/vpc/latest/privatelink/aws-services-privatelink-support.html

２．証明書の対応 公開CAとPrisma CAを両方信頼する システムの公開 CA ＋ 結合 CA バンドル Prisma CA initContainer Pod / プロセス SSL_CERT_FILE → 結合バンドル VPC Endpoint 公開 CA Prisma Prisma CA 同じプロセスが、VPCエンドポイント経由とPrisma Access経由の両方を使うため、 Prisma CAだけでなくシステムが元々持っているCAをバンドルする必要がある

実行環境ごとに異なるCAの配布方法 通常Pod、別リリース、動的Pod、ノードで対応する場所が変わる Dify Pod dify-api / … global.customCA initContainer CA bundle extraInitContainers initContainer initContainers CA bundle plugin-connector post-renderer initContainer ALB Controller（chart 1.8.4） bash + kustomize CA bundle LiteLLM / external-dns kaniko / 動的 Pod CA 入り base image Node / containerd ECR PTC / 事前コピー build Pod Plugin 実行環境 ecr.api / ecr.dkr S3 Gateway

LiteLLM migration Jobへの対応 Charｔ（Template）にinitContainerが存在しない場合 LiteLLM Helm release Deployment migrationJob initContainer initContainer：なし emptyDir CA bundle emptyDir CA bundle：なし SSL_CERT_FILE アプリ起動 SSL_CERT_FILE FileNotFoundError

CA設定の組込みとPod起動時の処理 YAML／post-rendererで定義を組み込み、initContainerでバンドルを作る Helm 3 Kubernetes external-dns values initContainers YAML Chart Pod initContainer install / upgrade initContainer ALB Controller（chart 1.8.4） values env / volume post-renderer Chart emptyDir bash + kustomize stdin ＋ initContainer stdout CA bundle アプリ SSL_CERT_FILE

Otel組み込み - Python起動時のCA設定 Go Node.js SSL_CERT_FILE Python NODE_EXTRA_CA_CERTS CA bundle / SSLContext Python 起動 PYTHONPATH OpenTelemetry / sitecustomize.py site.py → site-packages/*.pth import sitecustomize CA 互換モジュール /opt/pysite/sitecustomize.py × VERIFY_X509_STRICT OpenTelemetry / sitecustomize.py モジュールの配置だけでなく、実プロセスの読み込み順と設定を確かめる

エ ン ド ポ イ ン ト の 漏 れ が ノー ド 不 足 に な る 原因はautoscalingの対応漏れ。運用からはPendingとデプロイ失敗に見える autoscaling public IP Prisma CA ASG API × VPC Endpoint なし VGW → Prisma x509 エラー Autoscaler 停止 helm --wait Node × 15 分 timeout Pod 13 個 Pending

３ ． ノー ド の イメ ー ジ 取 得 を E C R に 寄 せ る 通常のpull経路をECRへ集約する。Pull Through Cacheを使用 こちらの VPC AWS サービス側 Pull Through Cache が取得 EKS Node containerd 初回 pull ecr.api / ecr.dkr PrivateLink ECR S3 Gateway 上流レジストリ API・マニフェスト・レイヤ Node NAT Gateway インターネット

Prisma Access 対応後の全体像 CloudFront SaaS 社内ユーザー WAFv2（us-east-1） Prisma Access IP 許可リスト VPC Origin VPC 上流レジストリ ALB VGW internal PTC / 事前コピー 0.0.0.0/0 SSL Forward Proxy Prisma CA EKS Node AWS Service Connection 対象 Pod / アドオン 公開 CA ＋ Prisma CA AWS API / Bedrock Interface EP containerd private DNS / SG 443 ECR sts / ec2 / bedrock-* / … Route 53 / WAFv2 / ACM Azure OpenAI / Vertex AI ecr.api / ecr.dkr SaaS / Marketplace S3 S3 Gateway VGWのIN／OUTはPrisma Access経由。外せない通信にはCAを届ける

まとめ（共有したかった学び） Prisma Access経由にする場合 1. CA を配るより、配る対象を減らす。ただし例外は必ず残る。最優先は STS、外せないのは Route 53 / WAFv2 / ACM。例外の処理まで含めて一つの設計にする。 2. 同じ設定が SDK・標準ライブラリ・サードパーティに独立して存在する。片方を潰しても再 発する。AWS_CA_BUNDLE と SSL_CERT_FILE は、その入口。 3. 一番ハマったのは、指定しなかった部分。IaC は書いた場所を守るけれど、書かなかった場 所は上流の既定値が有効になる。対症療法で閉じたものは、別の症状で戻ってくる。 IaCは重要。コーディングエージェントのおかげで今回の対応を１日で終えられた。 トイルの削減にも大きく貢献する

補足：CA配布とSTRICT回避の設定 CA配布を続けながら、CA再発行後にSTRICTの一時回避だけを撤去する global.customCA.enabled pythonSslRelaxStrict.enabled init.sh → CUSTOM_CA_ENABLED #STRICT# ca_filter() / #CA# VERIFY_X509_STRICT Chart YAML 別 Helm release post-renderer customCA 一時回避 ExternalSecret CA bundle SSL_CERT_FILE / NODE_EXTRA_CA_CERTS CA 再発行 → OFF