Cloud Runにアクセス制限をかける

この記事はしおだいふく Advent Calendar 2020 19日目の記事です。

Cloud RunはGCPが提供しているDockerコンテナ化されたアプリケーションのマネージドな実行環境です。 今年は（まだアルファ版ですが）traffic splittingが使えるようになったり、 最近ではminimum instancesが設定できるようになってどんどん使い勝手がよくなっています。

独自の特徴としては、Firebase Hostingと連携したバックエンドとして利用できることがあげられます。 Cloud Functions for Firebaseと連携する場合と比べると、Cloud Runはリージョンの制約がない¹こととminimum instanceが設定できるようになった点が強みです。 よっぽどの理由がない限りは、今後Hosting連携する場合にFunctionsを使うことはないでしょう。

そんなCloud Runですが、やはり業務利用にあたっては様々な理由でアクセス制限をかけたいという要望が湧いて出るものです。 残念ながら2020年12月現在ではIdentity Aware Proxyを利用することはできませんが、Cloud Runは自前の認証機構を備えています。

Cloud Run 起動元

Cloud Runでホストされているサービスを実行するにはCloud Run 起動元というロールが割り当てられていることが必要です。 権限を割り当てる操作はGCPコンソールのCloud Runのページで行うことができます。

以下の図は、allUsersという全てのユーザを表す特別なアカウントにCloud Run起動元を割り当てている例です。

これは誰でもアクセス可能である、つまりサービスとして公開されている状態となります。 本番環境ではこのような設定をすることになるはずです。

このロールの割り当てですが、allUsersという雑な設定だけでなく、個人のGoogleアカウントやGCPのサービスアカウント、 またGoogle Workspaceと連携したプロジェクトであればGoogleグループのアカウントに対して付与することができます。 これを利用すると、より粒度の細かなアクセスコントロールを実現することができます。

業務利用においては、Google Workspaceとの連携が特に便利です。 メーリングリストの所属ユーザ管理をそのまま開発環境のアクセス権限と連動させることができるので、二度手間にならずに済みます。

制限された環境へのアクセス方法

同様のアクセス制限はIAPやCloud Storageなどでも設定することができます。 GoogleのドメインにホストされているサービスであればCookieから適当に認証情報を拾ってくれるようなので、 Googleアカウントにログイン済みのクライアントからアクセスする場合は特別な設定は必要ありません。

しかし、Cloud Runの場合はGoogleの認証情報が連携されるドメインではありませんので、 自分で認証情報を設定して渡す必要があります。 Cloud Runのアクセス制限を通過するには、Bearer認証を使います。

以下のコマンドを実行し、gcloudツールを使ってIDトークンを発行します。

# ブラウザが開き、ログインを要求されます。ここでログインしたユーザとしてトークンを発行します。
$ gcloud auth login

# IDトークンが表示されます
$ gcloud auth print-identity-token

このようにして取得したIDトークンをリクエストのAuthorizationヘッダに埋めて送信します。

Authorization: Bearer <IDトークン>

ChromeであればModHeaderのような ブラウザ拡張等をつかうと簡単にAuthorizationヘッダが設定できると思います。

まとめ

まだそんなに使い込んだわけではないので、運用していくと苦しみとかがあるのかもしれません。 ただ、Firebase Hostingと連携したバックエンドにコードを書かずにアクセス制限がかけられることや、 Googleグループと連動した（IPアドレス制限よりも細かい）アクセスコントロールがかんたんに実現できるところが大きな魅力です。

Cloud Run信者の皆様は是非お試しください。