IAPを利用してCloud Run ユーザー認証を行う。

## はじめに

この記事は、
　[Cloud Run user auth for internal apps
](https://www.youtube.com/watch?v=ayTGOuCaxuc)という動画を参考に、『実際にやってみた』という記事になります。


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

以下はその必要となる構成になります。
![030-user-auth-for-internal-apps-architecture.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/e8ca2618-3dec-d82a-6c77-9c6026693631.png)


## Cloud Run Service をデプロイする。
[get-current-time](https://github.com/tomo8332/gcp-sample/tree/main/cloud-run/golang/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](https://github.com/tomo8332/gcp-sample/blob/main/cloud-run/golang/get-current-time/README.md) を読んで、Cloud Run サービスのデプロイを行なってください。


## Cloud Run Service の統合機能を使用して、ロードバランサを設定する。
『カスタムドメインを管理』 をクリック。
![001-manage-custom-domains.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/d04d9258-978f-f887-b9b5-1f8b1f7dc32a.png)

マッピングを追加 をクリック。
![002-add-mapping.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/048e5f59-9190-16fa-f398-e390bfcdab4a.png)

マッピングする `Cloud Run Service` を選択。
![003-select-the-sercice-to-be-mapped.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/e10ea14a-d57f-4205-2552-0fa7dfd04729.png)

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

統合機能を使用すると、CDN 有効化などの
既存のロードバランサの構成の一部が
上書きされる可能性があるので注意が必要。
![004-select-load-balancer-for-domain-mapping.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/9101f445-a7a9-5151-3ae9-5a54a4511b05.png)

ドメインを入力して、`SUBMIT` をクリック、統合とリソースが作成されるまで待機。
![005-add-domain-to-cloud-run.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/6a56f9d3-4f12-b71e-cecd-0e0eb6ce516d.png)

統合とリソースが作成されると、『欠損』状態のドメインマッピングが構成される。
![006-deficient-integration-functions.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/33e1df4e-276f-b324-0e5e-d20f1acd2ea1.png)

『欠損』状態を解除する為、DNSレコードを選択して、データ（IPアドレス）を取得。
![007-retrieve-data-from-dns-record.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/c904a007-785d-85fd-310f-92640b19b3a5.png)

[お名前.com](https://navi.onamae.com/top) などを使用して、
ドメインのDNS設定を行なってください。

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

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

逆にTTLが長いと、負荷は減りますが、
DNSレコードの変更が反映されるまで時間がかかります。
![008-register-dns-record-to-domain-name-server.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/a4181adc-075c-768b-072a-23190af83c8e.png)

DNS設定が完了すると、『保留中』状態に変わるので、  
SSL証明書がデプロイされるまで待機。
![009-pending-integration-functions.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/451f8192-67c4-b072-dbf9-6c1a282d1135.png)

SSL証明書がデプロイされ、『有効』状態となれば、ドメインマッピングの設定は完了
![010-enabled-integration-functions.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/cc3cdb70-90af-078a-f4ae-a36f1e7d48a5.png)


## Identity Aware Proxy (IAP) を設定する。
ユーザー認証については、`Identity Aware Proxy (IAP)` を利用します。
過去投稿の別記事でも同様の内容に触れていますので、  
まずは、`Identity Aware Proxy (IAP)` のみに触れたい場合、
こちらの[リンク](https://qiita.com/tomoyuki-suzuki/items/eb323b69a8f8164e1bb0)への記事を参照してください。

セキュリティ > `Identity-Aware Proxy` を選択。
![011-left-menu-security-iap.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/3458f089-574d-4ab8-0dba-4a15355df78a.png)

Identity-Aware Proxy API を有効化。
![012-enable-iap-api.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/53d63561-b140-e6b6-d154-2f14d71cf521.png)

APIが有効化されたら、`Identity-Aware Proxy` へ移動してください。
![013-enable-iap-api-go.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/a04e0a48-0271-3cbc-19fb-e5cf6780cf95.png)

IAPへ移動すると、ログイン画面でユーザーに表示される
OAuth同意画面の設定を促されますので、設定を続けてください。
![014-oath-consent-configuration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/f6a8aac6-fa94-58cf-bf1b-ebdeebcafc81.png)

利用するユーザータイプに応じて、選択を切り替える。
![015-external-or-internal.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/ca5c946d-8243-ae6a-cddf-78cd0bf7ff70.png)

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

![016-oauth-consent-screen-settings1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/bffec126-aaea-fbe7-4516-d144fcc05892.png)
![017-oauth-consent-screen-settings2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/c534ffc6-ba41-c643-ddbc-d5bd03df3fdb.png)

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

---

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

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

![018-iap-resource-enable.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/b003648f-6c32-792d-78f1-06fc3886e135.png)
![019-iap-resource-enable-check.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/8466b9b8-0144-c6fb-81de-8831398e6019.png)

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

ここで注意しなければならない点として、`admin` 権限を持ったアカウントで
IAPで保護されているリソースへのアクセスはできないと言うことです。
![020-dont-have-access-message.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/c711e0b8-88b7-5899-33e2-3c2079b6de92.png)


## 特定のユーザーやグループに対して、 IAP を経由するように設定する。
`Identity Aware Proxy (IAP)` の設定画面に戻って、
アクセスを許可したいバックエンドサービス（Cloud Run）を選択。
画面右に『プリンシパルを追加』が表示されるのでクリック。
![021-iap-check-principal-add.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/be6b300a-f707-a7f2-78a9-8f7a7f49a7d7.png)

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

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

ロール `IAP-secured Web App User` を付与することで、
特定のユーザーグループや個々のユーザーは、
IAPで保護されたサービスに対して、
IAPを経由してアクセスする事が許可された状態になります。
![022-add-principals-and-set-roles.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/f1b5d7ac-a12a-cf79-dfe8-eabc108a4d1d.png)


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

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

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

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

---

Cloud Run へ移動して、IAPを利用する為の権限を付与する為の
サービスを選択した状態で、『情報パネルを表示』をクリック。
![023-cloud-run-information-panel-display.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/6ca68e27-e0f6-05c7-b884-22cece2cf6c8.png)

『プリンシパルを追加』をクリックして、`Cloud Run Service` への
アクセスに、IAPを利用するように設定を行なってください。
![024-cloud-run-principal-add.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/54a94bde-22b0-2e37-5697-fa829a559853.png)

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

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

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

プロジェクト番号は、Google Cloud コンソールのTOPで確認ができます。
![025-iap-project-number.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/acb62745-580a-0fa9-57dc-e57b3399d31d.png)


## 匿名ユーザーや未認証によるアクセスを拒否する。
匿名ユーザーや未認証によるアクセスを拒否したい
Cloud Runサービスの詳細画面を開いて、
『`セキュリティ`』から『`認証が必要`』を選択して保存。
![026-cloud-run-security-update.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/8a95d95d-63e6-26cf-fc55-a938e263ce2a.png)

続けて、『`ネットワーキング`』から『`内部`』を選択。
『`外部アプリケーションロードバランサからのトラフィックを許可する`』
にチェックを入れて、保存。
![027-cloud-run-ingress-update.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/eb885c99-202f-ede2-adb8-f9a09c5b69f5.png)

Cloud RunサービスのTOPに戻って、下記の設定が表示されていればOK。
![028-cloud-run-access-authentication.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/172a6b8f-8f6b-27c2-7a05-868b56d483a1.png)


## カスタムドメインのみから、Cloud Run Service を実行できるかを確認する。
すべての作業及び設定が終えましたら、  
`Cloud Run Service` の実行を行なってみてください。

この時、`Cloud Run` をデプロイした際に生成されたURLでのアクセスは、
どのユーザーアカウントからもアクセスができない状態であること、
また、`カスタムドメイン` を利用する場合、 `Identity Aware Proxy (IAP)` を
経由するユーザーアカウントであれば、`Cloud Run Service`の実行が
行えることが確認できれば、作業は完了です。
![029-cloud-run-request-call.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/8a4d309a-009b-0131-9e79-efe3a83f2fd0.png)


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

`Identity Aware Proxy (IAP)` については、
以前にも[別記事](https://qiita.com/tomoyuki-suzuki/items/eb323b69a8f8164e1bb0)で触れていましたが、  
再度、学習することで、前回の学びにおいて、
少し理解が間違えている部分があることに  
気づくことができました。

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

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