CloudFront OAC × AWS Lambda Function URLs で作る認証付き簡易サイト というタイトルでLTしました
はじめに
2月20日に TECH BATON in 東京 〜今 Lambdaどうやって使ってる？ 〜 というイベントに参加し、LT登壇しました。CloudFront OAC × Lambda Function URLs で作る認証付き簡易サイト というタイトルで小ネタです。
内容
業務SaaSをマイクロフロントエンド構成で開発しており、CloudFrontのパスベースルーティングで認証・メイン画面・管理画面を別オリジン(ALB+ECS)に振り分けています。ここに新たにお客様向けのヘルプサイトを追加したいという要件がありました。
ヘルプサイトはマニュアルを表示するだけの簡易なサイトですが、外部に公開する必要はなく、他の画面と同じ認証情報でアクセスさせたいという条件がありました。静的サイト(Docusaurus/Sphinx等)も検討しましたが、認証の統合が課題でした。
よくあるケースとしてはcookieベースの方式です。前段にLambda@Edgeを置いてJWTを検証し、未認証であれば/authへ302リダイレクトする構成です。画像や動画(imgやvideoタグ)を含む全静的アセットもCDN層で保護できるため筋が良さそうでしたが、現構成の認証がlocalStorage + JWTだったためこの方式は使えませんでした。
代わりに採用したのがCloudFront OAC(オリジンアクセスコントロール)を利用したLambda Function URLs構成です。OACによりIAM認証とリソースポリシーでCloudFront経由のアクセスのみに制限できます。Authorization BearerヘッダーがOAC署名と競合する問題は業務JWTを別ヘッダーに分離する必要があります。なおcookie方式であればブラウザが<img>や<video>タグのリクエストにもcookieを自動付与するため全アセットを保護できますが、OAC方式ではこれらのHTMLタグからのリクエストにAuthorizationヘッダーを付与できません。そのため画像・動画は推測困難なパスに配置し、公開素材であることから完全な保護は割り切る判断をしました。POST/PUTが今後の要件として発生しなそうでしたので、うまくはまったと思います。
さいごに
他の登壇者様の発表として、数百数千のSingle Purpose Lambda構成から Lambdalithへ移行している事例や、Scala LambdaでのJVMオーバーヘッドを減らすためのカスタムラインタイム自作などおもしろいものが多かったです！詳しくはイベントサイトをご覧ください。
