---
title: EKSでZeroTrustNetworkに対応するためにやったこと
tags:  #jaws-ug #aws #eks  
author: [Akifumi Niida](https://image.docswell.com/user/nid)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LE3W4L14E5.jpg?width=480
description: JAWS-UG横浜 #103 - SRE支部コラボLT会 登壇資料
published: September 18, 26
canonical: https://image.docswell.com/s/nid/53JNYE-2026-09-18-182541
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LE3W4L14E5.jpg)

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
新居田 晃史


# Page. 2

![Page Image](https://bcdn.docswell.com/page/8EDKQNX57G.jpg)

自己紹介
•
新居田 晃史（にいだ あきふみ）
•
所属
–
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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/V7PKL5PDJ8.jpg)

背景
•
社内で安全に利用できる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が復号経路に入る


# Page. 4

![Page Image](https://bcdn.docswell.com/page/2JVVQP2GJQ.jpg)

１ ． 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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/5EGLWPLDJL.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/4JQY32YX7P.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/K74W1LW2E1.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LJ1YGLYKEG.jpg)

実行環境ごとに異なる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


# Page. 9

![Page Image](https://bcdn.docswell.com/page/GJWGKVGP72.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4EZLZ4L673.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/Y76WZ3WL7V.jpg)

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
モジュールの配置だけでなく、実プロセスの読み込み順と設定を確かめる


# Page. 12

![Page Image](https://bcdn.docswell.com/page/G75MWLMM74.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/9J29QL9RER.jpg)

３ ． ノー ド の イメ ー ジ 取 得 を 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
インターネット


# Page. 14

![Page Image](https://bcdn.docswell.com/page/DEY4WQ45JM.jpg)

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を届ける


# Page. 15

![Page Image](https://bcdn.docswell.com/page/VJNY9KY478.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/YE9P2VP4J3.jpg)

補足：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