はじめに

この記事は、
　Cloud Run user auth for internal apps
という動画を参考に、『実際にやってみた』という記事になります。

この記事で実施する事。

Cloud Run Service をデプロイする。
Cloud Run Service の統合機能を使用して、ロードバランサを設定する。
Identity Aware Proxy (IAP) を設定する。
特定のユーザーやグループに対して、 IAP を経由するように設定する。
Cloud Run Service サービスへのアクセスに IAP を利用するように設定する。
匿名ユーザーや未認証によるアクセスを拒否する。
カスタムドメインのみから、Cloud Run Service を実行できるかを確認する。

以下はその必要となる構成になります。

Cloud Run Service をデプロイする。

get-current-time を、git clone してください。

git clone https://github.com/tomo8332/gcp-sample.git

git cloneの実行が完了したら、cdコマンドを使って、対象のディレクトリ階層へ移動。

cd gcp-sample/cloud-run/golang/get-current-time

README.md を読んで、Cloud Run サービスのデプロイを行なってください。

Cloud Run Service の統合機能を使用して、ロードバランサを設定する。

『カスタムドメインを管理』をクリック。

マッピングを追加をクリック。

マッピングする Cloud Run Service を選択。

カスタムドメイン の統合機能に、Google Cloud Load Balancing を選択。

統合機能を使用すると、CDN 有効化などの
既存のロードバランサの構成の一部が
上書きされる可能性があるので注意が必要。

ドメインを入力して、SUBMIT をクリック、統合とリソースが作成されるまで待機。

統合とリソースが作成されると、『欠損』状態のドメインマッピングが構成される。

『欠損』状態を解除する為、DNSレコードを選択して、データ（IPアドレス）を取得。

お名前.com などを使用して、
ドメインのDNS設定を行なってください。

TTL（Time To Live）は、DNSレコードのキャッシュ（一時保存）期間を表します。
具体的には、DNS情報が他のサーバーやユーザーのシステムに
どのくらいの時間キャッシュされるかを秒単位で指定します。

TTLが短いと、DNSレコードの変更が早く反映されますが、
サーバーへの負荷が増える可能性があります。

逆にTTLが長いと、負荷は減りますが、
DNSレコードの変更が反映されるまで時間がかかります。

DNS設定が完了すると、『保留中』状態に変わるので、
SSL証明書がデプロイされるまで待機。

SSL証明書がデプロイされ、『有効』状態となれば、ドメインマッピングの設定は完了

Identity Aware Proxy (IAP) を設定する。

ユーザー認証については、Identity Aware Proxy (IAP) を利用します。
過去投稿の別記事でも同様の内容に触れていますので、
まずは、Identity Aware Proxy (IAP) のみに触れたい場合、
こちらのリンクへの記事を参照してください。

セキュリティ > Identity-Aware Proxy を選択。

Identity-Aware Proxy API を有効化。

APIが有効化されたら、Identity-Aware Proxy へ移動してください。

IAPへ移動すると、ログイン画面でユーザーに表示される
OAuth同意画面の設定を促されますので、設定を続けてください。

利用するユーザータイプに応じて、選択を切り替える。

OAuthの同意画面で、

同意を求めるアプリ名
ユーザーが同意に関して問い合わせるためのメールアドレス
デベロッパーの連絡先情報
をそれぞれ入力する。

ただし、一度設定してしまうと、サポートに問い合わせるか、
プロジェクトそのものを消さない限り消せなくなっている為、
操作は慎重に行う必要があります。

OAuthの同意画面の設定が終えたら、
Identity-Aware Proxy の設定画面に戻ってください。

この時、バックエンドサービスの Cloud Run は、
『エラー』ステータスを返していますが、
IAPを有効にすることで解消されます。

IAPが有効されたら、カスタムドメインを再リクエストしてください。
ログイン（認証）画面が表示されて、ログイン後も
『You don't have access』が表示されたら成功です。

ここで注意しなければならない点として、admin 権限を持ったアカウントで
IAPで保護されているリソースへのアクセスはできないと言うことです。

特定のユーザーやグループに対して、 IAP を経由するように設定する。

Identity Aware Proxy (IAP) の設定画面に戻って、
アクセスを許可したいバックエンドサービス（Cloud Run）を選択。
画面右に『プリンシパルを追加』が表示されるのでクリック。

アクセスを許可したいユーザーのアドレスとロールを選択して保存をクリック。

新しいプリンシパル：ユーザーのアドレス
ロール：IAP-secured Web App User

ロール IAP-secured Web App User を付与することで、
特定のユーザーグループや個々のユーザーは、
IAPで保護されたサービスに対して、
IAPを経由してアクセスする事が許可された状態になります。

Cloud Run Service サービスへのアクセスに IAP を利用するように設定する。

この設定が行われていない状態では、
IAPを経由したすべてのユーザーやグループは、
Cloud Runサービスにアクセスができてしまう状態です。

もう少し、比喩的に説明すると、IAPを経由した状態は、
街に入るための通行許可証を門番からもらった状態だと言えます。

さらにその先の城に入る為の効果を通行許可証は
持っていないはずが、Cloud Runサービス（城）に
入る為の制約がない為、通行許可証があるだけで、
城に入城できてしまうというおかしな状態となります。

そこで、Cloud Runサービス（城）に入場する為に、
そのIAP（通行許可証）に対して、入場を許可する
承認を行うのが、このステップになります。

Cloud Run へ移動して、IAPを利用する為の権限を付与する為の
サービスを選択した状態で、『情報パネルを表示』をクリック。

『プリンシパルを追加』をクリックして、Cloud Run Service への
アクセスに、IAPを利用するように設定を行なってください。

Cloud Runサービスへのアクセスに、IAPを利用する為の設定は、
下記のプリンシパルに対して、Cloud Run 起動元 の権限を付与します。

プリンシパル：service-[PROJECT-NUMBER]@gcp-sa-iap.iam.gserviceaccount.com
ロール：Cloud Run 起動元

PROJECT-NUMBER は、対象プロジェクトの番号を設定してください。

プロジェクト番号は、Google Cloud コンソールのTOPで確認ができます。

匿名ユーザーや未認証によるアクセスを拒否する。

匿名ユーザーや未認証によるアクセスを拒否したい
Cloud Runサービスの詳細画面を開いて、
『セキュリティ』から『認証が必要』を選択して保存。

続けて、『ネットワーキング』から『内部』を選択。
『外部アプリケーションロードバランサからのトラフィックを許可する』
にチェックを入れて、保存。

Cloud RunサービスのTOPに戻って、下記の設定が表示されていればOK。

カスタムドメインのみから、Cloud Run Service を実行できるかを確認する。

すべての作業及び設定が終えましたら、
Cloud Run Service の実行を行なってみてください。

この時、Cloud Run をデプロイした際に生成されたURLでのアクセスは、
どのユーザーアカウントからもアクセスができない状態であること、
また、カスタムドメイン を利用する場合、 Identity Aware Proxy (IAP) を
経由するユーザーアカウントであれば、Cloud Run Serviceの実行が
行えることが確認できれば、作業は完了です。

終わりに

今回の記事は、動画を視聴しまして、
実際に『手を動かしてみた』という内容でまとめました。

Identity Aware Proxy (IAP) については、
以前にも別記事で触れていましたが、
再度、学習することで、前回の学びにおいて、
少し理解が間違えている部分があることに
気づくことができました。

Identity Aware Proxy (IAP) について
少し勘違いした理解を持たれていましたら、
この記事を参考にしていただけると幸いです。

あとで『じっくり読みたい』、『繰り返し読みたい』と
思ってくれましたら、『ストック』へ登録、
この記事が読まれている方にとって、
参考になる記事となりましたら、『いいね』を
付けていただけますと、励みになりますので、
よろしくお願いします。