【初心者】GCP Identity-Aware Proxy (IAP), Access Context Managerを使ってみる (WEBサーバへのアクセス制限)

目的

• Google の提唱する BeyondCorp って何かな？と思っていたが、BeyondCorpはいろんな技術の組み合わせであり、Identity-Aware Proxy (IAP)やAccess Context Managerがその中の主要な構成要素とのこと。それらがどんなものか簡単に確認する。

GCP Identity-Aware Proxy (IAP) とは（自分の理解）

• 既存のWEBサービスに対して認証機能を挟むことができる仕組み。
• GCPのサービス(GCE, GAE, GKE)で作られているWEBサービスであれば、その前にIAPをそのまま追加できる。オンプレや他のクラウドで提供されているWEBサービスの場合、IAPコネクターというコンポーネントを追加することにより対応可能になる。

GCP Access Context Manager とは（自分の理解）

• GCPリソースへのアクセスをエンドポイント(＝アクセス元のPCやスマホ)のIPアドレスやOS等を条件として指定し、アクセスを制御できる仕組み。

やったこと

• 「PC - インターネット - LB - GCEインスタンス(nginx)」という構成を作り、インターネットから普通にGCPインスタンスにWEBアクセスができるようにする。（インターネット上からアクセス制限なしでWEBアクセスできる状態）
• LBの前にIAPを挟む設定を追加する。これにより、WEBサーバへのアクセス時に認証が行われるようにする。
• IAPにAccess Context Managerの設定を追加する。これにより認証の前にSRCIP制限がかかるようにする。

構成図

手順

事前準備

プロジェクトの作成

• プロジェクトを作成する。なお、Access Context Managerを使うには、組織に所属しているプロジェクトである必要がある。

GCEインスタンスの作成

• CentOS8のインスタンス「mksamba-nginx」を作成し、nginxをインストールしておく。

# yum install nginx
# systemctl enable nginx
# systemctl start nginx

インスタンスグループの作成

• 「非マネージドインスタンスグループ」として「mksamba-instancegroup」を作成し、インスタンス「mksamba-nginx」を所属させる。

ロードバランサ(HTTPS負荷分散)の作成

• ロードバランサ(HTTPS負荷分散)を作成する。
  • backend: 「mksamba-backend」を作成し、インスタンスグループ「mksamba-instancegroup」を指定する。
  • frontend: 「mksamba-frontend」を作成する。
    • プロトコル: https
    • IPアドレス: 「IPアドレスを作成」で固定IPを取得
    • 証明書：「新しい証明書の作成」- 「Google管理の証明書を作成する」で証明書を取得
• 今回はLBに紐づけるホスト名をmksambalb.xxx.com(仮名)とし、AWS Route53の設定にて、上記手順で取得した固定IPをそのmksambalb.xxx.comのAレコードとして登録しておいた。取得した固定IPとAレコードの登録内容が一致していれば証明書が発行される。

• ファイアウォールルールを追加する。(LB-GCEインスタンス間の通信を許可)
  • Src: 35.191.0.0/16, 130.211.0.0/22 (LoadBalancerのSRCIP)
  • Dst: インスタンス
  • Port: 80/tcp

IAP設定前の動作確認

• LBに紐づけたURLにアクセスして、普通にnginxの画面が表示されることを確認する。

IAP設定の追加

• IAMと管理 -> Idendity-Aware Proxyを選択し、IAPの画面へ移動する。
• IAPを有効化する。

• IAPの画面にて、まずOAuth同意画面を作成する。
  • User Type: 外部 (Googleアカウントならどんなアカウントでも認証に使える設定)
  • アプリケーション名: mksamba-nginx

• IAPの画面に戻り、バックエンドサービス「mksamba-backend」(先に作成したLB+GCEインスタンス)に対し、IAPのスイッチをONにして有効化する。

• mksamba-backend を選択し、「新しいメンバー」として適当なGoogleアカウント(例: [e-mail])、「ロール」として「Cloud IAP - IAP-secured Web App User」を追加する。

IAPの動作確認

• IAPの設定後、再度LBのURLにアクセスすると、nginxの画面ではなく、googleの認証画面が表示される。

• 「IAP-secured Web App User」 として登録したgoogleアカウントのID/Passを入力し認証をパスすると、nginxの画面が表示される。

• 登録されてないgoogleアカウントのID/Passを入力すると、「You don't have Access」のエラー画面となる。

Access Context Managerの設定

• セキュリティ -> Access Context Manager の画面を選択する。（プロジェクトではなく組織を選択する必要がある）。

• AccessControlLevel(アクセスを制限するルールみたいなもの)を新規作成する。今回は一番シンプルなルールであるSRCIP制限を設定する。(特定のCIDRからのアクセスのみ許可する設定)

• IAPの設定画面で、認証時の条件を追加する。前ステップのIAPの検証では「IAP-secured Web App User」としてGoogleアカウントを設定するのみだったが、今回はそこに「アクセスレベル」の設定を加える。

Access Context Managerの動作確認

• Access Context Managerの設定後、再度LBのURLにアクセスすると、設定したSRCIPからのアクセスの場合はGoogleの認証画面が表示される。また、設定したSRCIP以外からのアクセスの場合は接続エラー画面（認証失敗時と同じ）が表示される。

所感

• 初心者として以下の点につまづいた。
  • GCEがIAPに対応している、ということで、最初、単体のインスタンスをWEBサーバにしたが、IAP(https)の設定対象(リソース)として出てこなかった。LBとインスタンスグループが必要なことが後から分かった。
  • Access Context Manager を使用する場合、組織が必須ということに気づかなかった。組織なしのプロジェクトで作業していてその点で行き詰まり、組織配下のプロジェクトで作業をやり直した。
• まだあまりBeyondなかっこいい感じになってないので、他の構成要素についても勉強していきたい。