社内メンバーのみが Cloud Run にアクセスできるようにする
Cloud Run と Vercel や Netlify
開発環境やステージング環境を用意し、その上で検証を重ねた上で本番環境へデプロイする、という流れが一般的かと思います。
Vercel や Netlify では、お金を支払うことでプレビューサイトへのアクセス制限を付けることができます。
しかし、結構コストがかかることと、両方ともユーザー数課金であることから、ROI が良くないです。
そこで、Cloud Run を選ぶことが多いかと思います。
Cloud Run の開発環境の認証問題
Vercel や Netlify が自動で行ってくれる開発環境の認証は、Cloud Run では簡単にできません。
しかし、認証を設定していないと、Google 等にインデックスされてしまう可能性もあります。
基本的にはインデックスを防ぐ以前に、万が一に開発環境用のドメインが漏れた場合の対応策として、Basic 認証でも良いから認証を付けるべきというのがセキュリティ的な指針としてあると思います。
例えば開発環境にデプロイする時だけ、環境変数を使ってフロント側で認証を表示するという方法がありますが、ID & パスワードを共有する必要があり、面倒です。
そこで、以下の記事で紹介されている Identity-Aware Proxy を使用し、社内メンバーのみがアクセスできる Cloud Run を実現します。
設定方法
多くの企業が Google Workspace を採用して、同一ドメインのメアドを社内に配布していると思います。
そのドメインを持つ Google ユーザーに制限することで、簡単で統一的にアクセス管理を行うことができます。
まず、以下の画像のように、組織内にプロジェクトが入っている状態である必要があります。
そして、以下の画像での example-dev プロジェクトにデプロイされている Cloud Run に制限をかけたい、という状態です。
後は、先程も紹介した記事が、非常に丁寧にまとめられているため、そちらに従っていただく形になります。
しかし、一点だけ社内メンバーに限定するために必要なアクションがあります。
上記記事の「IAP 有効化」の所で、OAuth 同意画面の構成に関して言及されています。
ここで、以下のように、「内部」を選択する必要があります。
「内部」を選択すると、GCP と Google Workspace が紐付いているため、その組織のドメインからのアクセスのみを許可するように設定できます。
残りは上記の記事に従っていただければ、会社のメアドではアクセスでき、個人のメアドでは弾かれるようになっていると思います。
最後に
IAP と OAuth 同意画面の「内部」設定は非常に相性が良いです。
Cloud Run は、「内部トラフィックと Cloud Load Balancing からのトラフィックを許可する」という設定にしているため、IAP を迂回する術はありません。
一時的な設定ミス等で迂回できたとしても、「認証を必要とする」という設定になっているので、問題はありません。
今後社内メンバーが増えたとしても、Google Workspace でユーザーを作成するだけなので、管理コストを非常に低く保てます。
Basic 認証と比較すると、より安全で楽に運用できるかと思います。
こちらの記事が参考になれば、幸いです。
Discussion