BeyondCorp Remote Accessを支える技術 #1 GCP Cloud IAP connectorを試してみた

ども、ゲストのソラコム大瀧です。 在宅勤務のニーズが高まる昨今、Googleが提唱したBeyondCorp Remote Accessが話題ですね。

• BeyondCorp Remote Access | Google Cloud

VPNに代わって組織のシステムにセキュアにアクセスする手段をという触れ込みですが、「この製品を使えばBeyondCorp Remote Accessだ！」というものではなく、トラディショナルな境界セキュリティモデルに囚われずよりモダンなセキュリティソリューションを組み合わせてやっていこうというコンセプトモデルであり、Google社内のリモートアクセス構成をお手本にしつつ、日進月歩でその様相は移り変わるものと言えます。BeyondCorpのベースとなるセキュリティモデルであるZero Trust Networkを解説するネットワンさんの記事がわかりやすいです。

• 新解釈・ゼロトラストセキュリティ | ネットワンシステムズ

そこで本シリーズでは、Googleが提供するGCPおよびG SuiteのBeyondCorp Remote Accessに関するサービスをいくつかかいつまんでご紹介していきます。まずはリモートアクセスの中核となるクラウドの入り口部分であるCloud IAP(Identity-Aware Proxy)です。

Cloud IAPとIAP connector

GCPのCloud IAP(Identity-Aware Proxy)は名前の通り、認証機能付きのリバースプロキシです。Cloud Load Balancingの拡張機能として動作し、Google IdP(G Suite/Cloud Identity/Gmail)での認証に対応します。設定の様子は登場当時の拙著ブログ記事をご覧ください。

• Google Cloud Identity-Aware Proxy(Cloud IAP)でWebアプリに認証を追加する | :wq

ユーザー認証だけではアクセスする端末の安全性が担保できないため、先ほどのネットワンさんのブログにある「デバイスのチェック」や「条件のチェック」との連携が求められます。Cloud IAPではContext-Aware Accessという機能でG SuiteのMDMとの組み合わせで実現しますが、この辺りの詳細は次回に譲ります。

Cloud IAPは先述の通りCloud Load Balancingに依存するため、AWS ELBと同様にそのバックエンドはGCP内のVMインスタンスやGKEコンテナに限られます。本記事のテーマであるIAP connectorは、GCP外のシステムをCloud IAPのバックエンドとして利用する仕組みです。———といってもIAP connectorというマネージドサービスが提供されるわけではなく、その実体はGKEクラスタとそこで実行されるAmbassador API Gatewayコンテナです。構成図を以下に示します。

バックエンドは任意のWebAPサーバーを指定できるので、GKEクラスタのVPCとsite-to-site VPNやCloud Interconnectで他社クラウドやオンプレミスと閉域ネットワークで接続する構成にすると、既存WebアプリケーションのリバースプロキシとしてCloud IAPを置く構成がイメージできると思います。もちろんInternet FacingなWebアプリケーションをバックエンドとすることもでき、バックエンド側でCloud IAPからのリクエストか否かなどリクエスト真正性を評価したい場合はCloud IAPが付与するJWTトークンを手がかりにすると良いでしょう。

IAP connectorはCloud Deployment Managerによってデプロイするので、GKE周辺の個々の項目について詳細に把握する必要はありません。

1. IAP connectorの事前準備

以下のドキュメントの手順で進めていきます。

• オンプレミス アプリでの IAP の有効化  |  Identity-Aware Proxy のドキュメント  |  Google Cloud

必要なもの

• GCPアカウント
• 任意のインターネットドメイン

まずはGCPで新しいことをするときにお決まりの、APIの有効化です。以下のサービスのAPIを有効にします。

• Compute Engine API
• Google Kubernetes Engine API
• Cloud Deployment Manager API V2

つづいて、Deployment Manager(AWSで言うCloudFormationみたいなサービス)に付与する権限を設定します。Cloud IAMのメンバー一覧から[名前]列が「Google APIサービスエージェント」というアカウントにGKE管理者の権限を追加します。Google APIサービスエージェントの項目の鉛筆マークをクリックします。

[+ 別のロールを追加]リンクをクリックし、[Kubernetes Engine] -[Kubernetes Engine管理者]を選択します(サービス名がたくさんあるので、アルファベット順の「K」を目指してスクロールしましょう）。[保存]ボタンでダイアログを閉じます。

続いて、Cloud IAPに設定するTLS証明書を設定します。自前の証明書をインポートするのも良いですし、AWSのACMと同様のGCPマネージド証明書で発行しても良いでしょう。今回はマネージド証明書を発行してみました。手順はCloud Load Balancing向けをベースに進めます。

あらかじめドメインに以下のCAAレコードをセットしておきます。(画面はAmazon Route 53の例)

CAA 0 issue "letsencrypt.org"
    0 issue "pki.goog"

Cloud Load Balnacingのページにある「詳細設定メニュー」リンクをクリックします(めっちゃ小さい表示なので頑張って探しましょう)。

[証明書]タブをクリックします。

[+ SSL証明書を作成]をクリックします。

任意の名前を入力、[Googleマネージドの証明書を作成する]を選択し、[ドメイン]に用意したドメイン名を入力します。[作成]ボタンをクリックすれば証明書作成が開始します。

この時点ではロードバランサが未作成なので、予約済みIPアドレスが定まらずGCPによるDNSレコードの検証が失敗します。検証は自動で何度か行われるので、証明書の作成完了を待たずにCloud Deployment Managerのステップに進みましょう。

2. IAP connectorのセットアップ

IAP connectorのCloud Deployment Manager用の設定ファイルがGitHubに公開されているので、そのファイルを編集し、Cloud Deployment Managerを実行する流れになります。まずは git clone で手元に持ってきます。

$ git clone https://github.com/GoogleCloudPlatform/iap-connector
Cloning into 'iap-connector'...
remote: Enumerating objects: 16, done.
remote: Counting objects: 100% (16/16), done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 239 (delta 3), reused 6 (delta 1), pack-reused 223
Receiving objects: 100% (239/239), 73.56 KiB | 353.00 KiB/s, done.
Resolving deltas: 100% (55/55), done.
$ cd iap-connector/
$ ls
CONTRIBUTING.md                deployment-manager-shared-vpc/ iap-connector.yaml
LICENSE                        iap-connector.py               terraform-and-helm/
README.md                      iap-connector.py.schema
$

設定ファイルは iap-connector.yaml です。以下の項目を編集します。

• resources.properties.zone: GKEクラスタを展開するゾーンを入力します
• resources.properties.serviceAccountName: 手順1で設定したGoogle APIサービスエージェントのアカウント名
• resources.properties.routing.name: 任意の設定名。Deployment Managerのデプロイ名になります
• resources.properties.routing.mapping.source: Cloud Load Balancingに割り当てるドメイン
• resources.properties.routing.mapping.destination: 転送先
• resources.properties.tls: 手順1で作成したSSL証明書名

# Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

imports:
- path: iap-connector.py

resources:
- name: iap-connector
  type: iap-connector.py
  properties:
    zone: asia-northeast1-a
    serviceAccountName: XXXXXXXXX@cloudservices.gserviceaccount.com
    routing:
     - name: iaptest-takipone-com
       mapping:
        - name: host
          source: iaptest.takipone.com
          destination: dev.classmethod.jp
    tls:
     - iaptest-takipone-com
    preemptible: true
    initialNodeCount: 1
    replicas: 1

末尾3行はオプションのプロパティです。/iap-connector.py.schemaファイルに説明があります。今回は動作確認用途なので、GKEクラスタノードの利用料金をなるべく安くなるようにしてみました。

設定ファイルを書き換えたら、gcloud コマンドでCloud Deployment Managerのデプロイを実行します。

$ gcloud deployment-manager deployments create iap-takipone-com  --config=iap-connector.yaml

デプロイの進行状況はCloud Deployment Managerのページで確認できます。

GKEの構成自体はごくごく一般的なものなので、エラーで止まる場合は設定ファイルの変更箇所におかしなところが無いかを見ていく感じになるでしょう。私はresources.properties.routing.mapping.hostが固定値(host)ということに気づかず適当に編集してトラブルシューティングに苦戦しました。

デプロイが完了したらHTTPロードバランサの予約済みIPアドレスが採番されているので、ドメインのAレコードに登録しましょう。しばらくするとマネージドSSL証明書のプロビジョニングが正常に完了するはずです。

3. 動作確認

現時点ではCloud IAPが無効なので、アクセス制限なしでリバースプロキシが動作します。Webブラウザでドメイン宛にアクセスしてみると...

転送先のページが表示されました！今回は転送先がdev.classmethod.jpなのでDevelopers.IOが表示されます。

ではCloud IAPを有効にしてみましょう。Cloud IAPのページにあるHTTPSロードバランサの一覧からdefault/<設定名>のIAP列のスイッチをオンにします。バックエンドへのバイパスに関する警告が出ますが、今回は動作確認のため無視します。[構成要件を参照し、ドキュメントに従ってGCEリソースを構成しました]のチェックをオンにし「構成」をクリックします。

続いて、右側ペインある「メンバーを追加」をクリックしてアクセスできるユーザーを選択します。

[新しいメンバー]にメールアドレスやG Suiteのドメインを指定してアクセスを許可するユーザーを指定し(ちなみにここで[ロールを選択]から[Cloud IAP] - [IAP-secured Web App User]を選択するとContext-Aware Accessのアクセスレベルと連動した条件の追加ができますが今回は省略)、[保存]をクリックします。

では、先ほどのWebブラウザをリロードします。

Googleの認証画面が表示され、Cloud IAPの動作が確認できました！

まとめ

BeyondCorp Remote Accessを実現するための技術として、Cloud IAP connectorをご紹介しました。

Internet FacingなWebサービスであれば、最近Google IdPのSAMLアプリがContext-Aware Accessに対応したので、そちらによるシングルサインオン連携の方がおそらく便利です。Cloud IAPはSAML連携などが難しいトラディショナルなWebシステムを対象としており、IAP connectorはオンプレミスにあるそれらをゼロトラストセキュリティの次元まで引っ張り上げるために有効なツールだと思います。

参考URL

• Googleがリモートワークを支援する「BeyondCorp Remote Access」を提供、ゼロトラストのセキュリティを実現可能 - GIGAZINE
• AWSとGCPのVPN接続を複数パターン試してみる（Classic VPN編） | Developers.IO