「外部に出す入口(デモのUI/入出力)」が nlq-dev 側に全部揃っているなら、セキュリティと運用を単純化するために
- Dev-Portal(API/DB側)は外部公開しない(VPC内限定)
- nlq-dev だけ外部公開する(AllowListで制限)
- nlq-dev → Dev-Portal は VPC内の内部通信で呼ぶ
に寄せるのが一番きれいです。
この構成が成立する条件
- ユーザー(顧客含む)が触るUIが nlq-dev 側にある
- 例:「nlq-dev に質問入力 → 結果表示」まで完結する
- nlq-dev が Dev-Portal を内部で叩ける
- 同一EKSなら K8s Service DNS
- 別クラスタ/別基盤でも、internal ALB などで VPC内到達できればOK
こうすると何が良い?
- 公開面が nlq-dev だけになるので、WAF/AllowListなどの設定箇所が減る
- Dev-Portal を外に出さないので、誤って
/docsや内部APIが露出する事故を避けやすい - 「暫定セキュリティ(ログイン未実装)」でも守りやすい
実装・インフラ設定の要点(最低限)
1) Dev-Portal を非公開化
- Ingress / Public ALB を 無効化(もしくは internal-only に)
- Service は ClusterIP(外に出さない)
- もし internal ALB を使うなら internal scheme にする
2) nlq-dev だけ外部公開+AllowList
- nlq-dev の入口(ALB/Ingress/WAF)に AllowList を設定
- 顧客が固定IPなら顧客IPも追加、固定できないなら踏み台/SSMなど別途検討
3) nlq-dev → Dev-Portal の接続先を内部URLに固定
DEVPORTAL_BASE_URL=http://dev-portal.<namespace>.svc.cluster.local(同一クラスタ例)- 別基盤なら internal ALB のDNS名など(VPC内限定)
注意点(ここだけ押さえると安全)
- 「Dev-PortalのフロントUIも顧客に見せたい」 なら、この方針は成り立ちません
→ その場合は Dev-Portal UI も外に出す必要がある(ただし入口を1つに統合する工夫は可能) - オフショアが Dev-Portal のAPIに直接触ってデバッグしたい場合でも、Dev-Portal非公開なら
→ 踏み台経由のポートフォワード(または SSM)で内部に入る運用になります
(顧客には不要、開発者だけの話)
まとめ
あなたの前提(デモは「nlq-devで質問→結果」)なら、
「nlq-devだけ外部公開」「Dev-PortalはVPC内限定」
が、暫定セキュリティとして最もシンプルで現実的です。
もし今の構成が「nlq-dev と Dev-Portal が同じEKS内」か「別EKS/別基盤」かだけ分かれば、内部URLの指定やALBの切り方を、より具体的な手順に落として書けます。
コメントを残す