はじめに

この記事では、Google Cloudを使用して簡単なWordPressサイト環境を構築した際に、個人的に注意すべきだと感じたポイントをまとめています。筆者は普段AWSをメインに扱っているため、AWSとの比較を交えながら解説します。

なお、本記事では詳細な設定手順は要点に絞って記載し、Google Cloud初心者向けに基本的な内容を中心に構成しています。そのため、内容の正確性や実用性を完全に保証するものではないことをご了承ください。

目次

  • 今回構築した環境の概要
  • ファイアウォールルールに関するポイント
    • コンソールからSSH接続を有効にする方法
    • ロードバランサーのヘルスチェックを通過させる方法
  • VMインスタンスに関するポイント
    • 注意すべきメタデータの設定
  • ロードバランサーに関するポイント
    • SSL証明書とHTTPS接続で陥りやすい問題
  • データベースに関するポイント
    • プライベートIPでの接続を有効にする方法
  • まとめ

1. 今回構築した環境の概要

ネットワークリソース

  • VPCネットワーク
  • サブネット
    • Public Subnet
    • Protected Subnet x2
  • Cloud NAT
    • Cloud Router
  • VPCファイアウォールルール

コンピューティングリソース

  • グローバル外部アプリケーション ロードバランサ
    • HTTP/HTTPSの両方でアクセス可能に設定
  • Compute Engine VMインスタンス
    • 踏み台サーバー
    • コンソール経由でのSSH接続を許可
    • Webサーバー x2
    • コンソール経由でのSSH接続を許可
    • ミドルウェアとしてApache, PHP, MySQLをインストール
    • OSはDebianを使用
  • インスタンスグループ

データベース

  • Cloud SQL for MySQL
    • プライベートIPで接続

大まかには上記のような環境を構築しました。次項から、設定でつまづきやすかったポイントについて解説します。

2. ファイアウォールルールに関するポイント

2-1. コンソールからSSH接続を有効にする方法

Google Cloudには、VMインスタンスにブラウザのコンソール画面からSSH接続できる機能があります。これはAWSの「セッションマネージャー（SSM）」に似た機能です。

この機能を利用するにはいくつか注意点があるため、AWSのSSMと比較しながらポイントを解説します。

AWSのSSM接続との違い

AWSでSSM接続を有効にするための主な要件:

  • 対象のEC2インスタンスにAmazonSSMManagedInstanceCoreポリシーを含むIAMロールがアタッチされていること。
  • アウトバウンド（外向き）のHTTPS（ポート443）トラフィックがセキュリティグループで許可されていること。
  • SSM Agentがインストールされ、起動していること（多くはデフォルトで導入済み）。
    参考：Session Manager を設定する

Google CloudでコンソールからSSH接続を有効にするための主な要件:
コンソールからSSH接続を行うには、以下の2点が重要です。

1. Identity-Aware Proxy (IAP) のTCP転送を利用可能なIAM権限

Google CloudのコンソールからのSSH接続は、「Identity-Aware Proxy（IAP）のTCP転送」という機能を利用します。これは、Google Cloudが提供する踏み台サーバーのようなもので、外部IPアドレスを持たないVMインスタンスに対し、許可されたユーザーが暗号化されたトンネル経由で安全にアクセスできるようにする仕組みです。
参考：TCP 転送の概要

この機能を使うには、まず接続したいユーザーにIAPのTCP転送に関するIAMロールを付与する必要があります。具体的には、IAP-secured Tunnel User (roles/iap.tunnelResourceAccessor) というロールです。その他、Compute EngineインスタンスへのSSHアクセス権限なども必要に応じて確認してください。
参照：IAP TCP 転送のロールを付与する

2. IAPからVMインスタンスへの接続を許可するファイアウォールルール

AWSのSSMでは、特定のIPアドレスからの接続を許可する必要はありません。しかしGoogle CloudのIAPは、特定のIPアドレス範囲からVMインスタンスに接続します。

そのため、コンソールからSSH接続したいVMインスタンスに適用されるファイアウォールルールで、35.235.240.0/20 からのSSHポート（TCP:22）への上り（内向き）アクセスを許可する必要があります。
参照：ファイアウォール ルールを作成する

Google Cloudでは「インスタンスにロールを付与する」のではなく「ユーザーにロールを付与する」点、そして「特定のIPアドレスからのアクセスを許可する必要がある」点がAWSとは大きく異なります。

2-2. ロードバランサーのヘルスチェックを通過させる方法

Google CloudのロードバランサーにもAWSと同様にヘルスチェック機能があり、これが正常に通過しないとインスタンスへのトラフィックが遮断されます。AWSでは、ヘルスチェック用のパスやポートに対するセキュリティグループの設定が主な確認項目です。

Google Cloudでヘルスチェックを通過させるには

Google Cloudのヘルスチェックで最も重要なポイントは、特定のIPアドレス範囲からのアクセスを許可する必要があることです。許可すべきIPアドレスは以下の通りです。

130.211.0.0/22
35.191.0.0/16

参考：プローブ IP 範囲とファイアウォール ルール

例えばヘルスチェックにポート80番を使用する場合、ファイアウォールルールで上記IPアドレス範囲からのTCP:80への上りアクセスを許可しなければ、ヘルスチェックは永遠に失敗し続けます。

一通りの設定を終えたのにWebサーバーに接続できない、またはヘルスチェックが異常なままという場合は、このファイアウォールルールを見直してみてください。

3. VMインスタンスに関するポイント

3-1. 注意すべきメタデータの設定

Google CloudのVMインスタンスには「メタデータ」という概念があります。インスタンスに関する情報をキー・バリュー形式で設定するものです。ここでは特に注意すべきポイントを解説します。
概要：メタデータの概要

プロジェクトレベルとインスタンスレベルのメタデータ

メタデータは、プロジェクト全体に適用される「プロジェクトレベル」と、個々のインスタンスに適用される「インスタンスレベル」で設定できます。プロジェクトレベルのメタデータはプロジェクト内の全インスタンスに継承されるため、設定の共通化には便利ですが、意図しない設定が適用されてトラブルの原因になる可能性もあります。インスタンスごとに設定を分けたい場合は、安易にプロジェクトレベルのメタデータを設定せず、個別にインスタンスレベルで設定することをお勧めします。

トラブル時に見直すべき設定

メタデータ以外で、動作がおかしいと感じた時に見直すと良いかもしれない設定項目を挙げます。

  • プロジェクト全体のSSH認証鍵をブロック
    まっさらなインスタンスを作成したはずなのに、/etc/passwdファイルを見ると作成した覚えのないユーザーが存在したり、登録した覚えのない公開鍵が~/.ssh/authorized_keysに登録されていたりすることがあります。
    これは、公開鍵もメタデータと同様にプロジェクト全体で設定でき、そこに登録された公開鍵がプロジェクト内の全インスタンスに自動で配布されてしまうためです。

この設定が直接的なエラーを引き起こすことは稀ですが、セキュリティ上好ましくないため、不要であればインスタンスの設定で「プロジェクト全体のSSH認証鍵をブロック」にチェックを入れましょう。

ただし、この設定を有効にした状態で、デフォルト以外の作業用ユーザーに固有のキーペアでSSH接続しようとして、コンソールの「SSH認証鍵」に手動で公開鍵を登録すると、SSH接続ができなくなる場合があります。このようなケースでは、インスタンスに直接ログインし、手動で~/.ssh/authorized_keysファイルに公開鍵を追記する必要があります。
参考：メタデータ ベースの SSH 認証鍵を使用する VM からのプロジェクトの SSH 認証鍵をブロックする

  • Cloud API アクセススコープ
    ファイアウォールルールに問題がないにも関わらず、VMインスタンスから他のGoogle Cloudサービス（Cloud StorageやCloud SQLなど）へ接続できない場合があります。

その場合は、インスタンスの「Cloud API アクセススコープ」が「すべてのCloud APIに完全アクセス権を許可」になっているか確認してみてください。デフォルト設定では他のリソースへの操作権限が制限されていることがあります。最小権限の原則は重要ですが、開発環境などで特に要件がなければ、この設定にしておくとスムーズに作業を進められます。
参考：GKE のアクセス スコープ

4. ロードバランサーに関するポイント

4-1. SSL証明書とHTTPS接続で陥りやすい問題

AWSでは、ACMで発行またはインポートした証明書を、どの種類のロードバランサーにも比較的容易にアタッチできます。

一方Google Cloudでは、証明書の種類とロードバランサーの種類の組み合わせに制約があり、AWSと同じ感覚で設定するとうまくいかないことがあります。

SSL証明書の種類

Google CloudのSSL証明書にはいくつか種類があり、それぞれアタッチできるロードバランサーが異なります。

  • Compute Engine 証明書（従来の証明書）
  • Googleマネージド: グローバル外部アプリケーションLBなどで利用可能。
  • セルフマネージド: リージョン外部/内部アプリケーションLBなどで利用可能。

  • Certificate Manager 証明書（新しい証明書管理サービス）

  • Googleマネージド: 多くのHTTPSロードバランサーで利用可能。推奨。
  • セルフマネージド: 多くのHTTPSロードバランサーで利用可能。

証明書とロードバランサーの組み合わせは、要件や用途に応じて事前にしっかり確認しないと、HTTPS接続の設定で沼にハマる可能性があります。特にこだわりがなければ、対応範囲が広いCertificate Manager証明書を利用するのが便利です。

参考：
SSL 証明書の概要
証明書を管理する

5. データベースに関するポイント

5-1. プライベートIPでの接続を有効にする方法

LAMP構成ではWebサーバーとデータベースの接続が必要です。セキュリティの観点から、この接続はプライベートIPで行うことが推奨されます。

AWSでRDSを作成する場合は、特別な事前準備なしにプライベートIP接続を選択できます。

プライベートIPアドレスで接続を設定するには

一方Google Cloud（Cloud SQL）では、プライベートIP接続を有効にするために、事前に「プライベートサービスアクセス」という設定が必要です。これにより、VPCネットワークとGoogleが管理するサービス（Cloud SQLなど）のネットワークがプライベートに接続されます。

この設定を行う際、接続に使用するIPアドレスの範囲を予約する必要がありますが、特に希望がなければ自動割り当てで問題ありません。

参考：プライベート IP の使用方法の詳細

プライベートサービスアクセスを設定するには

プライベートIP接続を設定しようとすると、以下のような権限不足のエラーが表示されることがあります。

プライベートサービスアクセス接続は必須です
ネットワーク「hogehoge-vpc」には、プライベートアクセス接続が必要です。
...(以下省略)

このエラーは、操作しているユーザーに以下の権限が不足している場合に発生します。

compute.networks.list
compute.addresses.create
compute.addresses.list
servicenetworking.services.addPeering

個別に設定するのが大変な場合、Compute Network Admin (roles/compute.networkAdmin) ロールを付与するのが簡単です。

この権限は他の設定では不要なことが多く、この段階で初めて発覚する可能性があります。権限の変更は管理者に依頼が必要な場合もあるため、あらかじめこのエラーの可能性を把握しておくとスムーズです。
参考：プライベート サービス アクセスを構成する

6. まとめ

以上が、Google Cloudを初めて触って気づいた注意点です。全体としては、AWSと仕様が大きく異なるメタデータやSSL証明書のあたりが、特につまづきやすいポイントだと感じました。

今回は「まず動くものを作る」ことを目標としたため、次回は最小権限の原則など、よりベストプラクティスに沿った設定にも挑戦したいと思います。