Cloud Run で内部ユーザーを認証する際は IAP を使うが、 今までは LB が必要だった。今月のアップデートで LB がなくても Cloud Run で IAP が使えるようになったので便利という話。
まえがき
Google Cloud は無料枠が多くコンソールも使いやすく個人クラウドカジュアルケチ勢にはありがたいサービスで、 GCE をはじめ GKE や Firestore など便利に使わせてもらっている。
とりわけ最近使ってるのは Cloud Run。コンテナを走らせるサービスなので一般的な Web app のコードを書くだけで使えるし、コストはアクセスした分だけなので激安。Service だけでなく Job を走らせるのにも割と安くすむし、 Lambda っぽいのがほしければ Cloud Run functions を使えば自動でビルドしてくれる。Cloud Scheduler や PubSub との連携も簡単。
デプロイすると自動的にドメインが生成されて外部からアクセスできるように簡単にできるし、内部用途でも IAM 認証をかけて特定の SA に絞れたりするのも嬉しい。Outbound についても、VPC / Subnet 内への通信とかできるようになって連携しやすくなった。
…と褒めまくっているが、案外ネックなのはユーザーの認証/認可だった。具体的には、適当な個人ツールを作って Google アカウントでアクセスを自分だけに絞りたいケース。
Cloud Run での内部ユーザー認証・認可
やりたいことは以下の「内部ユーザーを認証する」にあたり、IAP を利用してとのこと。
IAP 便利そうだしいいじゃんってなるのだけど、 IAP は（今まで）ロードバランサーが必須だった。なので、雑プロジェクトを運用にするには結構高い。ほとんど使わない LB に月3kくらいかかるのはちょっとね…
そうすると Sidecar としてコンテナごとに oauth2-proxy を立てるだとか、Firebase auth を利用して app に認証認可を組み込むとかがケチ的選択肢になるが、ちょっと気軽でない感じ。
ということで今までは同じプロジェクト内にある GKE に Cloud Run を向いた ExternalName Service を作って、その Service を向いた Ingress を作り、そこでクラスタ内ですでに使っている oauth2-proxy を利用しつつ認証・認可・Proxyするようにしていた。ただそれはそれで Cloud run 側で IAM 認証が使えなくなって境界ベースの防御になるのでイケてない前時代 SOHO セキュリティになっていた。
Cloud Run と IAP の組み合わせが LB 無しでできるようになった
という悩みを長年抱えていて新しい Service を作るたびにもにょっていたのだが、今月 Cloud Run で IAP が LB なしで使える機能が出ていたのに気付いた。
便利すぎる。 LB で立てるよりも保護の範囲も広がるらしい。ということで使ってみた。
Google Cloud Project を Organization 配下にする
今は Preview 版だからか Cloud IAP の制約なのか知らないが、Project が Organization 配下でないとこの機能は使えない。
なので、Organization 配下にないような個人アカウントのプロジェクトは、まず Cloud Identity または Google Workspace をセットアップして今使っている Project を Organization 配下に移動する必要がある。
ちょっと敷居が高く聞こえるが、Cloud Identity はドメインさえあれば無料ですぐ利用できるし、移動しても特にリソースや権限は今と変わらず使えるので作ってしまえば良い。
Project 移動の注意点としては、変更がすぐに反映されるとは限らないこと。IAM も Org 操作も、少し時間がかかることが多かった。
Cloud Run で IAP を有効にする
Project が Org 配下になって少し待つと、Cloud Run に IAP の設定項目が現れる。
あとは IAP を有効化し、Policy を編集して許可したいユーザーを設定し、保存する。そうすると IAP の保護下になるので、URL にアクセスすると Google 認証画面が出てきて、特定のアカウントでしかアクセスできなくなる。
注意点
いくつか引っかかりもあったので共有。
Org 配下にしてから IAP 有効化の操作をするべき
Org の配下にする前に IAP を API 経由で有効にしようとすると以下のエラーになる。
IAP is only available for projects that are part of an Organization.
Org 配下でないときは仕様なので正しいのだが、自分が行ったときは Org 配下にした後もこのエラーが出ていた。これはおそらく Org 化前に試した際のキャッシュによるもので、1,2時間待てばこのエラーの頻度は減っていった（最初はガチャ性があるので何回か試すと良い）。 Org 配下にしてから有効化するとこんなことにはならなかったかもしれない（もっと別の場所のキャッシュかもしれないが）。
組織外のアカウントは Principal に追加しても認可されない
ドキュメントにもあるが、Cloud Run の IAP で Principal として設定できるのは組織に属するユーザーのみである（正確に言うと、他のユーザーも設定はできるが動作しない）。そのため、普段の gmail アカウントを Principal に入れてアクセスしても IAP のエラー画面が返ってくる。
Cloud Identity を作るときに組織のユーザーも作っているはずなので、それを使うようにすれば良い。
Ingress は All にする
Internal にしていると IAP 経由だろうが外からのアクセスは Not found が返ってくるので、IAP を有効化するときに All にしておく必要がある。
何かあれば Cookie を消す
IAP の設定を変えた際は、Cloud Run の URL に紐付く Cookie は一旦消したほうが良い。そうすると認証が必ず再度走るので確実な挙動確認ができる。
…ということで Cloud Run で微妙だった点が解決した話だった。今後も積極的に使っていこうと思う。
