はじめに
こんにちは！マイクロアドでインフラエンジニアをしている大泉です。
今回はGoogle CloudのCloud Load Balancing（以下、CLB）にOAuth2認証を導入したお話をします！
背景として、権限分掌の観点から、ネットワーク構築を担当するチームとアプリケーション構築を担当するチームでプロジェクトを分けて運用しています。
各アプリケーションごとに個別のネットワーク接続を構成すると管理・運用が複雑になるため、共有VPCホストプロジェクトがネットワーク接続を一元的に担い、各アプリケーションのVPCはこの共有VPCを経由して通信する構成としています。
こちらがCLB導入前の構成図です。
今回の対応では、このアプリケーションをインターネットからCLB経由でアクセス可能にするとともに、セキュリティ強化の観点から追加でOAuth2認証を導入します。
また、外部から直接アクセスされるCLBはセキュリティの観点からもアプリケーションがあるプロジェクトとは分離し、既存の共有VPCホストプロジェクト上に構築しました。
これにより、アプリケーション側の改修を最小限に抑えつつセキュリティを向上させることができました。
この記事では、その具体的な設定方法についてご紹介します。
ぜひ、ご自身のプロジェクトにも応用してみてください！
Identity-Aware proxy（IAP）とは
IAPとは、Google Cloud上でホストされているアプリケーションやリソースへのアクセスを、ユーザーのIDに基づいて制御するGoogle Cloudのサービスです。
IAPは、この制御を実現するために、認証の仕組みとしてOAuthを内部的に利用しています。
詳しくはGoogle Cloud公式のドキュメントをご覧ください。
cloud.google.com
構成図
こちらがCLB導入後の構成図です。プロジェクトAのVMインスタンスがプロジェクトBの共有VPCを経由してインターネットに公開されるサービスです。
今まではアプリケーション側で認証機能を実装しておりました。今回、プロジェクトAのVMインスタンスに手を加えずに認証機能を用意する必要がありました。
したがって、プロジェクトBにCLBを設置して認証機能を持たせました。
事前準備
CLBとVMインスタンス間はプロジェクトを跨ぐので、以下の設定が必要になります。
- プロジェクトB（共有VPCホストプロジェクト）での内部サブネット作成
- 内部サブネット範囲へのプロジェクトAのVMインスタンス内部IPの所属
- CLBによるSSL終端と証明書の準備
- ローカル環境でのgcloudコマンド使用
- OAuth2認証用クライアントIDとシークレットの発行
- 認証済みクライアントに対するアプリケーションのURIの追加
CLB構築
今回は認証機能を持たせるため、始めにCLBを構築しました。
前提として、プロジェクトAのVMインスタンスはプロジェクトBの共有VPCを利用していることとします。
CLBはフロントエンド、バックエンド、ルーティングルールで構成されます。
今回はインターネットのアクセスに対応するため、グローバル外部アプリケーションロードバランサを使用します。
ここからは順を追ってCLB構築についてお話します。バックエンドの設定がやや複雑になるので注意が必要です。
フロントエンドの設定
フロントエンドはインターネットから来るリクエストをどう受け取るか決める部分です！
以下の設定をしました。
- IAPを使うのでHTTPSのプロトコルを設定
- インターネットからの通信を受け付けるため、静的外部IPを取得・付与
- SSL終端になるので事前に準備した証明書を設定（Googleマネージド証明書での設定も可能）
- DNSでCLBの外部IPとドメインの紐づけ
フロントエンドはコンソールから設定するだけで比較的簡単に構築できます！
バックエンドの設定
続いて、バックエンドの設定です。プロジェクトを跨ぐ場合はバックエンドサービスをプロジェクトAで作成し、プロジェクトBのCLBに設定します。
- バックエンドサービスにインスタンスをアタッチするため、プロジェクトAでネットワークエンドポイントグループ（NEG）を作成
- プロジェクトAのバックエンドサービスで、先ほど作成したNEGを選択
ここまでの操作でプロジェクトAのバックエンドサービス作成が完了します。
次に、プロジェクトBでCLBのバックエンドを設定します。
- CLB構築のバックエンドの画面で、バックエンドサービスとバックエンドバケット設定
- 画像の通り、プロジェクトAのプロジェクトIDと先ほど作成したバックエンドサービスを選択
ルーティングルールの設定
単純なホストとパスのルールを選択し、プロジェクトAのバックエンドサービスを選択します。
以上でCLB構築が完了します！
ここからはOAuth2を導入するためIAPの有効化と権限付与を設定します。
IAP有効化と権限付与
事前準備で用意したクライアントIDとシークレットを使い、CLBのバックエンドに設定します。
gcloudコマンドを利用して設定します。
gcloud --project=プロジェクトAのID \
compute backend-services update プロジェクトAのバックエンド名 \
--iap=enabled,oauth2-client-id=用意したクライアントID, \
client-secret=用意したクライアントシークレット --global
以下コマンドでIAPの項目を確認できれば有効化完了です！
gcloud compute backend-services describe プロジェクトAのバックエンド名 --global
IAPを有効にしたら、アクセスを許可するユーザまたはグループに権限を付与します。
今回は、IAP-secured Web App User（roles/iap.httpsResourceAccessor）権限を付与しました。
これは、IAPで保護された Webアプリケーションへのアクセス権限になります。
構築時の落とし穴
プロジェクトを跨ぐCLB設定には様々な落とし穴がありました。
幾つか挙げてみましたので、参考にしていただければ幸いです！
CLB構築時の問題と解決案
-
CLBのバックエンド設定
問題: CLBのバックエンドに別プロジェクトのVMインスタンスを紐づけられない。
解決案: VMインスタンスのネットワーキング設定でCLBがあるプロジェクトで作成したサブネットを利用する設定にする。 -
CLBのヘルスチェックが失敗
問題: CLB構築後にバックエンドのVMに対するヘルスチェックが失敗する。
解決案: FWルールでCLBヘルスチェックの範囲（35.191.0.0/16,130.211.0.0/22）を許可する。 -
権限付与してもアクセスできない
問題: IAPを有効にした状態でバックエンドアプリケーションが自前でリダイレクトを返す場合、ループが発生する。
解決案: バックエンドのポート設定を80から443に変更する、またはアプリケーション側のリダイレクト設定を調整する。
おわりに
この記事では、Google CloudのCLBにIAPを導入して、VMインスタンス側に手を加えずに認証する方法をご紹介しました。
ポイントとしては、プロジェクトを跨いだバックエンド設定やNEGの利用、IAPの権限付与、ヘルスチェックやリダイレクトの落とし穴への対応です。
CLBで認証を完結させることで、アプリケーション側の改修を最小限に抑えつつセキュリティを強化できる点が大きなメリットでした。
また、Google CloudのIAPは権限管理が細かくできるため、チームやサービス単位で安全にアクセス制御できることが分かりました。
Google Cloudで社内サービスを安全に公開したい方や、IAPの活用方法を知りたい方の参考になれば幸いです。
今回の設定内容は応用が可能なので、ぜひご自身のプロジェクトに合わせて試してみてください！
インフラエンジニア絶賛採用中
マイクロアドでは技術への探究心があり、最新の技術・動向について積極的に学び活かす意欲を持った仲間を募集しています！
またインフラエンジニアだけでなく、サーバサイド、機械学習エンジニアなど幅広く募集しています！
気になった方は以下からご応募ください！
