API Gateway Private API × オンプレ接続でハマった話
- make
- 1 日前
- 読了時間: 5分
はじめに
久々の投稿です。
今回は、社内NWからのみ利用するちょっとしたWebツールを作ろうと
API Gateway の Private API を使って実現する際にハマったことをネタにしようと思います。
要件と対応方法
Webツールの要件は、
社内向けの簡易ツール
そんなに頻繁に使うものではない
IAM認証やOIDCを設けるほどではないので社内NWなら誰でも利用可
社外からはアクセスできないようにしたい
という、ありがちな要件でした。
あれこれ用意するのも面倒だし、アクセス頻度も大したことがないので、
APIGatewayのPrivateAPIを1つ用意し、複数メソッドで画面表示（返却をHTMLにする）から実行（ツール本来の処理）まで一貫して行うようにする方法を取ることにしました。
構成イメージ
公式ドキュメントを参考に、以下のような構成を取りました。
API Gateway：Private API
API Gateway 用 Interface VPC Endpoint を作成
API と VPC Endpoint を関連付け
Route53 の エイリアスレコード
{rest-api-id}-{vpce-id}.execute-api.{region}.amazonaws.com
を使って API を呼び出す
API Gateway のリソースポリシーは
VPCエンドポイント経由のみ許可
それ以外は拒否
という公式でよく紹介されている設定
これで「VPCエンドポイント経由でのみアクセスできるはず」と考えていました。
起こった問題
VPC 内からは問題なく疎通する
同一 VPC 内に立てた EC2 から API を呼ぶと、問題なくレスポンスが返っており、
想定どおりの挙動でした。
社内NW（オンプレ）からは Forbidden
ところが、Transit Gateway 経由で VPC に接続している社内NWから API を呼ぶと、
403 Forbidden が返却されました。
VPC エンドポイントのセキュリティグループも社内CIDRを許可しており、
ネットワーク的には到達できるはずですが、
API Gateway のリソースポリシーで拒否されているように見えました。
調査して分かったこと
curl --resolve を使うと疎通する
試しに {rest-api-id}-{vpce-id}.execute-api... を
VPCエンドポイントの ENI の IP に強制的に名前解決してアクセスすると、
正常に疎通することが分かりました。
この挙動から、
社内NWからのアクセスは VPCエンドポイントを経由していない
と判断されてしまっているようです。
混乱のもと
私はてっきり、VPCエンドポイントと関連付けをして
{rest-api-id}-{vpce-id}.execute-api.{region}.amazonaws.com
という呼び出し方をすると、
「rest-api-id」に対応するPrivateAPIを「vpce-id」に対応するVPCエンドポイント経由で
呼ぶということをやってくれるからおのずとVPCエンドポイント経由になるんだという
理解でいました。
そしてPrivateAPIのリソースポリシーにはVPCエンドポイント経由のみ許可とするのが
一般的なやり方であるということも下記参考の公式ブログから判断していました。
しかし、よくよくプライベートAPIの公式の説明をみると、、
プライベート API は、Amazon VPC 内からのみ呼び出せる REST API です。API にアクセスするには、インターフェイス VPC エンドポイントを使用します。これは、VPC で作成するエンドポイントネットワークインターフェイスです。インターフェイスエンドポイントは、プライベート IP アドレスを経由して AWS PrivateLink サービスにプライベートにアクセスできるテクノロジーである AWS により強化されています。 Direct Connect を使用してオンプレミスネットワークから Amazon VPC への接続を確立し、この接続を介してプライベート API にアクセスすることも可能です。いずれの場合も、プライベート API へのトラフィックは安全な接続を使用し、パブリックインターネットからは隔離されます。トラフィックは、Amazon ネットワークを離れません。
後半部分には特にVPCエンドポイントに関する言及はありません。
あくまでVPC内からアクセスできるというだけで、VPCエンドポイント経由でないとアクセスできないものというわけではなかったようです。
言い換えると今回のように、FQDN に vpce-id が含まれていても、
それだけで VPCエンドポイント経由が保証されるわけではない
ということのようです。
対処方法
今回は社内NWからであればアクセスできてOKだったの以下で対応しました。
リソースポリシーはVpcSourceIpでの制御とする
API Gateway のリソースポリシーで aws:VpcSourceIp により社内CIDRのみ許可 →VPCエンドポイント経由のみ許可をやめる
特徴
オンプレ DNS 構成を変更せずに対応可能
社内NWを信頼境界とする環境ではシンプルで分かりやすい
ネットワーク設計と API 制御の考え方が一致する
留意点
社内NWのCIDR変更時には設定の見直しが必要
IP アドレスを前提とした運用となる
VPCエンドポイント経由を前提とした構成にするには？
今回は深堀りできていないのですが、おそらく
オンプレ DNS から VPC の Route 53 Resolver へ名前解決をフォワード
Interface VPC Endpoint の Private DNS を利用
API Gateway のリソースポリシーで aws:SourceVpce を条件に制御
といった対応などを行う必要がありそうです。
そしてここまでのことをやるならカスタムドメインでWAFも掛けたPublicAPIを構成したほうがよいかもしれません。
特徴
API へのアクセス経路を VPC エンドポイントに固定できる
IP アドレスに依存しないため、CIDR 管理が不要
AWS のクラウドネイティブな構成と親和性が高い
留意点
オンプレ DNS の設計変更が必要
フォワーダ設定など、ネットワーク側の調整が前提となる
セキュリティ観点での考え方
今回のように、
社内NWが明確な信頼境界である
Transit Gateway 等で接続された閉域ネットワークである
API は内部向けであり、認証を前提としない用途である
という条件下では、
aws:SourceVpce と aws:VpcSourceIp の間で、実質的なセキュリティ強度に大きな差はない
と考えてよいと思いますが、昨今のゼロトラストな考え方にはならない点は注意が必要です。
本格的な運用を想定するものであれば、認証付きAPIを用意するのが賢明です。
まとめ
今回は、PrivateAPIとVPCエンドポイントを関連付けしたときの思い込みから発生したハマりポイントをご紹介しました。同じ悩みに当たってしまった方の参考になれば幸いです。
コメント