2023年は「Cloud Run を触って覚える」をテーマとした一人アドベントカレンダーを一人で開催しており、Cloud Run のさまざまな機能や、Cloud Run でよく使う構成などを実際の使い方と一緒にご紹介しています。
16日目は Cloud Run サービスと Identity-Aware Proxy についてご紹介します。
Cloud Run の概要は技術評論社さまのブログ「gihyo.jp」に寄稿した記事で解説していますのでこちらもぜひご覧ください。
Identity-Aware Proxy とは
Identity-Aware Proxy (IAP) は Cloud Run などのアプリケーションへのアクセスを保護するためのサービスです。ユーザー ID を確認し、コンテキストに応じてアクセスの許可・拒否を判断させることができます。
Identity-Aware Proxy
IAP はアクセスを許可するユーザーを Google アカウント、または Google グループなどで IAM を使用して指定します(外部 ID を許可することもできます)。IAP は Load Balancer に設定することで、Load Balancer へのアクセス時に IAP によるユーザーの認証画面を表示し、アクセスが許可されたユーザーであることが確認できたらバックエンドの Cloud Run にリダイレクトするような振る舞いをします。
IAP を使うと Cloud Run 側でユーザーのアクセスを許可するかどうかを判断する必要がないため、アクセス制御をかんたんに導入でき便利です。一方で細やかな認可 (例 : ユーザーの属性によって API リクエストを許可するか判断する) を行いたい場合は Cloud Run 側で実装する必要があります。また、Cloud CDN との併用はできません。
実装方法は下記のドキュメントが参考になります。また、試す場合でも Load Balancer は SSL を有効化しておく必要があります。
この記事では、Cloud Run サービスに IAP を適用する手順を紹介します。
Cloud Run サービスをデプロイする
(このアドベントカレンダーでは既に何度もやっていますが) まずは Cloud Run サービスをデプロイします。
今回は IAP から渡される X-Goog-IAP-JWT-Assertion ヘッダーに渡される JWT の中からアクセスしてきたユーザーを表示するようなアプリケーションを用意しました。
まず Cloud Shell を起動します。
Cloud Shell の起動
Git リポジトリをクローンし、ディレクトリに移動します。
git clone git@github.com:suwa-yuki/cloudrun-iap-sample.git
cd cloudrun-iap-sample
このサンプル コードは X-Goog-IAP-JWT-Assertion ヘッダーの有無を確認しているだけのシンプルな Express アプリケーションです。
const express = require('express')
const app = express()
app.get('/', (req, res) => {
const jwt = req.header('X-Goog-IAP-JWT-Assertion')
res.send(`
<html>
<body>
<code>${jwt ? jwt : "No JWT header"}</code>
</body>
</html>
`)
})
const PORT = 8080
app.listen(PORT, () => {
console.log(`App listening on port ${PORT}`)
})
Cloud Build のコマンドを実行し、コンテナ イメージをビルド・プッシュします。PROJECT_ID は自分の Google Cloud プロジェクトに置き換えて実行してください。
gcloud builds submit \
--region asia-northeast1 \
--tag gcr.io/PROJECT_ID/cloudrun-iap-sample
Cloud Run へのデプロイはコマンドで行います。Cloud Run のコンソールから行いたい場合は下記コマンドのオプションを参考に設定してください。
gcloud run deploy \
--image gcr.io/PROJECT_ID/cloudrun-iap-sample \
--platform managed \
--allow-unauthenticated \
--ingress internal-and-cloud-load-balancing \
--region asia-northeast1
数秒 ~ 数分後、Cloud Run サービスのデプロイが完了します。外部ロードバランサのアクセスのみ許可しているので、直接アクセスはできません。
外部ロードバランサとカスタム ドメインを設定する
IAP はロードバランサの一部として動作するので、Cloud Run サービスの手前に置く外部 HTTPS ロードバランサを作成します。また HTTPS の必要があるためカスタム ドメインも必要です。
Cloud Run Integration を使うと、外部ロードバランサとカスタム ドメインの構成を少ない手順で構築できます。今回はこれを使います。下記の記事でも紹介していますのでよければご覧ください。今回はドメインを既に取得している前提で進めます。
[統合] のタブを開き [インテグレーションを追加] をクリックします。
インテグレーションの追加
[カスタム ドメイン - Google Cloud Load Balancing] を選びます。
カスタム ドメインの追加
前の項で用意したドメインを指定します。なお、ここの設定で複数の Cloud Run サービスにルーティングする設定もできます。
ルーティングの設定
作成されるまで数分 ~ 数時間かかります。作成が無事完了すると、DNS レコードに設定すべきグローバル IP が払い出されるので、DNS に A レコードとして設定します。
IAP を設定する
IAP のコンソールを開きます。
Identity-Aware Proxy API をまだ有効にしていなければ [API を有効にする] をクリックします。
Identity-Aware Proxy API の有効化
OAuth 同意画面を作成
OAuth 同意画面を作成する必要があります。OAuth 同意画面は Google アカウントに対して、アプリケーションに Google アカウントの認証情報を渡す許可 (認可) を取るために必要な画面です。
[同意画面を構成] をクリックします。
同意画面の構成
[User Type] は [内部] に設定し、[作成] をクリックします。
User Type の設定
アプリ情報を登録します。[アプリ名] はここでは Cloud Run IAP Sample に、[ユーザー サポート メール] は自分のメールアドレスを設定します。
アプリ名とユーザー サポート メールの設定
[デベロッパーの連絡先情報] に自分のメールアドレスを設定し、[保存して次へ] をクリックします。
デベロッパーの連絡先情報
以上で設定は完了です。[スコープ] はスキップしても問題ありません。
IAP の有効化
IAP のコンソールに戻ります。
IAP を有効化できるリソースが一覧され、外部 HTTPS ロードバランサを設定した Cloud Run のバックエンド サービスが表示されます。[IAP] のトグルをクリックします。
バックエンド サービス一覧
構成要件を満たしているか確認が求められます。[有効にする] をクリックします。
IAP の有効化
数秒で有効化できます。[ステータス] が [OK] になっていることを確認します。
IAP の有効化の確認
IAP へのアクセス
ここで、Cloud Run に設定したカスタム ドメインにアクセスしてみましょう。Google アカウントが求められるように変わりました。
Google アカウントの確認
Google アカウントを選択すると、アクセスが許可されていない旨のメッセージが表示されます。
アクセス拒否
IAP 経由でアクセスするためには Google アカウント (または組織、Google グループ) に対して「対象の IAP へのアクセスを許可するロール」を付与する必要があります。IAP のコンソールから設定できます。
IAP のコンソールでバックエンド サービスをチェックボックスで選択し、右ペインに出てくる [プリンシパルを追加] をクリックします。
プリンシパルの追加
[新しいプリンシパル] にアクセスを許可させたいメールアドレスを入力します。[ロール] は IAP-secured Web App User を設定します。最後に [保存] をクリックします。
プリンシパルの設定
設定後、アプリにアクセスできるようになっていることが確認できます。X-Goog-IAP-JWT-Assertion に含まれる JWT が表示されます。
アプリの動作確認
反映までに少し時間がかかる場合がありますので、アクセス拒否の画面が出てしまう場合は数分経ってから確認してみてください。
まとめ
外部 HTTP ロードバランサやカスタム ドメインの設定が Cloud Run Integration によって簡単に設定できるようになったため、IAP までの一通りの設定もかなり楽になりました。コンテナ アプリケーションを社内のみに限定公開するようなケースにぜひ採用してみてください。
Discussion