はじめに

知ったことメモ

IAPのTCPフォワーディング

• この機能は、パブリックIPアドレスを持たないVMインスタンスに対して、インターネット経由で安全にSSHやRDP接続を行うための機能。
• 使い方
  • IAP用ファイアウォールルールの作成
    • TCP3389番ポート
    • ソースレンジ：35.235.240.0/20 (Google が所有するパブリックIPアドレスレンジ)
    • ターゲット：タグrdp-server
  • 接続ユーザーへの権限付与(roles/iap.tunnelResourceAccessor)
  • 接続コマンド実行
    • gcloud compute start-iap-tunnel windows-vm 3389 --local-host-port=localhost:13389 --zone=asia-northeast1-a
    • コマンドを実行したままRDPアプリでlocalhost:13389に接続するとVMにつながる
• メリット
  • VMにパブリックIPが不要になりセキュリティが向上する
  • IAMの認証認可によりポリシーを細かく制御できる
  • 踏み台サーバーが不要になる
• デメリット
  • 制限事項がある
    • この機能は、データの一括転送を対象としていない。悪用を防ぐためにレート制限を設定できる権限を有する。
    • この機能は、非アクティブ状態が1時間続くとセッションを自動的に切断する。前述のコマンドでは再確立を試みる。

やったこと

まとめ

1. Windows および Linux VM の作成: Terraform を使用して VM を作成する方法
2. スタートアップスクリプト: VM 起動時に自動的にソフトウェアをインストールする方法
3. IAP を使用した安全な接続: 外部 IP なしで VM に接続する方法
4. Managed Instance Group: 複数の VM を 1 つのグループとして管理する方法
5. ロードバランサー: 複数の VM にトラフィックを分散する方法
6. VM Manager: パッチ管理を行う方法

主要なポイント

• 最小権限の原則: サービスアカウントには必要最小限の権限のみを付与
• Infrastructure as Code: Terraform を使用してインフラをコード化
• セキュリティ: IAP や OS Login を使用してセキュリティを強化
• 高可用性: MIG とロードバランサーを使用して高可用性を実現
• コスト最適化: 不要なリソースは速やかに削除

リソース構成図

• IAM & セキュリティ: サービスアカウントとアクセス制御に関するリソース
• ネットワーク: ファイアウォールルールによるトラフィック制御
• 単一 VM インスタンス: 個別の VM インスタンス（Windows、Linux、OS Login 有効）
• Managed Instance Group: 複数 VM の管理と自動スケーリング
• ロードバランシング: トラフィック分散とヘルスチェック
• バックアップ: スナップショットによるバックアップと復元
• 外部接続: ユーザーからの接続経路（IAP、直接接続、ロードバランサー）

前提条件

• Google Cloud アカウントとプロジェクトが作成済み（Project ID: cookbook-251226）
• Windows 端末（PowerShell）と Cursor エディタを使用
• Terraform がインストールされていること
• gcloud CLI がインストールされ、認証済みであること

ステップ 1: 作業環境の準備

1.1 作業ディレクトリの作成

# Terraform用のディレクトリを作成
mkdir terraform
# アプリ用のディレクトリを作成（必要に応じて）
mkdir app

1.2 必要な API の有効化

# Compute Engine APIを有効化（VMインスタンス作成に必要）
gcloud services enable compute.googleapis.com --project=cookbook-251226

# IAM APIを有効化（サービスアカウント作成に必要）
gcloud services enable iam.googleapis.com --project=cookbook-251226

# OS Config APIを有効化（OS Login、VM Managerに必要）
gcloud services enable osconfig.googleapis.com --project=cookbook-251226

# Container Registry APIを有効化（コンテナイメージ使用に必要）
gcloud services enable containerregistry.googleapis.com --project=cookbook-251226

ステップ 2: Terraform 設定ファイルの作成

2.1 メインの Terraform ファイル（main.tf）

# Terraformのバージョンとプロバイダの設定
terraform {
  required_version = ">= 1.3.0"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 6.0.0"  # 最新の安定版を指定
    }
  }
}

# Google Cloudプロバイダの設定
provider "google" {
  project = "cookbook-251226"
  region  = "asia-northeast1"  # デフォルトのリージョンを指定
}

# 変数の定義
variable "project_id" {
  description = "Google Cloud Project ID"
  type        = string
  default     = "cookbook-251226"
}

variable "region" {
  description = "Region for GCE resources"
  type        = string
  default     = "asia-northeast1"
}

variable "zone" {
  description = "Zone for GCE resources"
  type        = string
  default     = "asia-northeast1-a"
}

2.2 VPC ネットワークの作成

# VPCネットワークの作成
resource "google_compute_network" "vpc_network" {
  name                    = "vpc-network"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "vpc_subnet" {
  name          = "vpc-subnet"
  ip_cidr_range = "10.0.0.0/24"
  region        = var.region
  network       = google_compute_network.vpc_network.id
}

2.3 ファイアウォールルール（RDP 用）の作成

# RDPトラフィックを許可するファイアウォールルール（Azureにおける同等のサービス名：Azure Network Security Groups）
resource "google_compute_firewall" "allow_rdp" {
  name    = "allow-rdp"
  network = google_compute_network.vpc_network.name

  allow {
    protocol = "tcp"
    ports    = ["3389"]  # RDPポート
  }

  source_ranges = ["0.0.0.0/0"]  # すべてのIPアドレスから許可（本番環境では制限推奨）
  target_tags  = ["rdp-server"]
}

2.4 サービスアカウントの作成

# VM用のサービスアカウントの作成
resource "google_service_account" "vm_service_account" {
  account_id   = "vm-service-account"
  display_name = "Service Account for VM instances"
  description  = "Service account for Compute Engine instances"
}

# サービスアカウントに必要な権限を付与（最小権限の原則）
resource "google_project_iam_member" "vm_service_account_roles" {
  for_each = toset([
    "roles/compute.instanceAdmin.v1",  # インスタンス管理に必要
    "roles/iam.serviceAccountUser"     # サービスアカウントの使用に必要
  ])
  project = var.project_id
  role    = each.key
  member  = "serviceAccount:${google_service_account.vm_service_account.email}"
}

ステップ 3: Windows 仮想マシンの作成

3.1 Windows VM の定義

# Windows仮想マシンの作成（Azureにおける同等のサービス名：Azure Virtual Machines）
resource "google_compute_instance" "windows_vm" {
  name         = "windows-vm"
  machine_type = "e2-medium"  # 必要に応じて変更可能
  zone         = var.zone

  boot_disk {
    initialize_params {
      image = "windows-cloud/windows-2022"  # Windows Server 2022イメージファミリー（常に最新版を使用）
      size  = 50  # ディスクサイズ（GB）
      type  = "pd-standard"  # ディスクタイプ
    }
  }

  network_interface {
    network    = google_compute_network.vpc_network.name
    subnetwork = google_compute_subnetwork.vpc_subnet.name
    access_config {
      # 外部IPを自動割り当て（RDP接続に必要）
    }
  }

  service_account {
    email  = google_service_account.vm_service_account.email
    scopes = ["https://www.googleapis.com/auth/cloud-platform"]
  }

  metadata = {
    enable-oslogin = "TRUE"  # OS Loginを有効化（後述のIAP接続で使用）
  }

  tags = ["windows-server", "rdp-server"]
}

• イメージファミリー（windows-cloud/windows-2022）を使用することで、常に最新の Windows Server 2022 イメージが使用されます
• enable-osloginを有効化することで、OS Login 機能が使用可能になります
• 作成した VPC ネットワークとサブネットを使用することで、ネットワーク構成を制御できます

• access_configを設定することで、外部 IP が自動的に割り当てられ、RDP 接続が可能になります
• tagsを使用して、ファイアウォールルールと連携できます
• VPC ネットワークとサブネットを使用することで、ネットワーク構成をより細かく制御できます

• 外部 IP あり: メリット：直接接続可能、デメリット：セキュリティリスクが高い
• 外部 IP なし + IAP: メリット：セキュリティが高い、デメリット：IAP の設定が必要

ステップ 4: Linux 仮想マシンの作成と NGINX のインストール

4.1 Linux VM の定義（スタートアップスクリプト付き）

# Linux仮想マシンの作成（Azureにおける同等のサービス名：Azure Virtual Machines）
resource "google_compute_instance" "linux_vm" {
  name         = "linux-vm"
  machine_type = "e2-medium"
  zone         = var.zone

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12-bookworm-v20240110"  # 最新のDebian 12イメージ
      size  = 30
      type  = "pd-standard"
    }
  }

  network_interface {
    network    = google_compute_network.vpc_network.name
    subnetwork = google_compute_subnetwork.vpc_subnet.name
    access_config {
      # 外部IPを自動割り当て（SSH接続に必要）
    }
  }

  service_account {
    email  = google_service_account.vm_service_account.email
    scopes = ["https://www.googleapis.com/auth/cloud-platform"]
  }

  metadata = {
    enable-oslogin = "TRUE"  # OS Loginを有効化
  }

  # スタートアップスクリプトでNGINXをインストール
  metadata_startup_script = <<-EOT
    #!/bin/bash
    apt-get update
    apt-get install -y nginx
    systemctl start nginx
    systemctl enable nginx
    # ホスト名を表示するようにカスタマイズ
    sed -i "s/nginx/Google Cloud Cookbook - $HOSTNAME/" /var/www/html/index.nginx-debian.html
  EOT

  tags = ["http-server", "linux-server"]
}

• metadata_startup_scriptを使用することで、VM 起動時に自動的にソフトウェアをインストールできます
• これにより、手動でのインストール作業が不要になり、再現性が向上します

4.2 HTTP 用ファイアウォールルールの作成

# HTTPトラフィックを許可するファイアウォールルール
resource "google_compute_firewall" "allow_http" {
  name    = "allow-http"
  network = google_compute_network.vpc_network.name

  allow {
    protocol = "tcp"
    ports    = ["80"]  # HTTPポート
  }

  source_ranges = ["0.0.0.0/0"]  # すべてのIPアドレスから許可
  target_tags   = ["http-server"]
}

ステップ 5: Identity-Aware Proxy（IAP）を使用した Windows VM への安全な接続

5.1 IAP 用ファイアウォールルールの作成

# IAP TCP Forwarding用のファイアウォールルール
# IAPを使用することで、外部IPなしでも安全にVMに接続可能
resource "google_compute_firewall" "allow_iap_rdp" {
  name    = "allow-iap-rdp"
  network = google_compute_network.vpc_network.name

  allow {
    protocol = "tcp"
    ports    = ["3389"]  # RDPポート
  }

  # IAPのTCP Forwardingで使用されるCIDR範囲
  # この範囲は、Google Cloud IAPが使用するIPアドレスを含みます
  source_ranges = ["35.235.240.0/20"]
  target_tags   = ["rdp-server"]
}

• IAP を使用することで、外部 IP アドレスを公開せずに VM に接続できます
• 35.235.240.0/20は、Google Cloud IAP が使用する CIDR 範囲です

• IAP 使用: メリット：セキュリティが高い、外部 IP 不要、デメリット：IAP Desktop アプリのインストールが必要
• 直接 RDP: メリット：標準的な RDP 接続、デメリット：外部 IP が必要、セキュリティリスクが高い

5.2 IAP 権限の付与

# IAP-Secured Tunnel Userロールを付与（IAP TCP Forwardingに必要）
# このロールは、ユーザーまたはグループに付与する必要があります
# 注意: 実際のユーザーやグループのメールアドレスに置き換えてください
resource "google_project_iam_member" "iap_tunnel_user" {
  project = var.project_id
  role    = "roles/iap.tunnelResourceAccessor"  # IAP TCP Forwardingに必要なロール
  member  = "user:your-email@example.com"  # 実際のユーザーメールアドレスに置き換え
}

ステップ 6: Managed Instance Group（MIG）の作成

6.1 インスタンステンプレートの作成

# インスタンステンプレートの作成（Azureにおける同等のサービス名：Azure Virtual Machine Scale Sets）
# テンプレートを使用することで、同一設定のVMを複数作成可能
resource "google_compute_instance_template" "nginx_template" {
  name         = "nginx-template"
  machine_type = "e2-medium"
  zone         = var.zone

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12-bookworm-v20240110"
      size  = 30
      type  = "pd-standard"
    }
  }

  network_interface {
    network    = google_compute_network.vpc_network.name
    subnetwork = google_compute_subnetwork.vpc_subnet.name
    access_config {
      # 外部IPを自動割り当て
    }
  }

  service_account {
    email  = google_service_account.vm_service_account.email
    scopes = ["https://www.googleapis.com/auth/cloud-platform"]
  }

  metadata_startup_script = <<-EOT
    #!/bin/bash
    apt-get update
    apt-get install -y nginx
    systemctl start nginx
    systemctl enable nginx
    sed -i "s/nginx/Google Cloud Cookbook - $HOSTNAME/" /var/www/html/index.nginx-debian.html
  EOT

  tags = ["http-server"]
}

# Managed Instance Groupの作成（Azureにおける同等のサービス名：Azure Virtual Machine Scale Sets）
resource "google_compute_instance_group_manager" "nginx_group" {
  name               = "nginx-group"
  base_instance_name = "nginx"
  zone               = var.zone
  target_size        = 2  # 初期インスタンス数

  version {
    instance_template = google_compute_instance_template.nginx_template.id
  }

  # 自動修復を有効化
  auto_healing_policies {
    health_check      = google_compute_health_check.nginx_health_check.id
    initial_delay_sec = 300
  }
}

• Managed Instance Group（MIG）を使用することで、複数の VM を 1 つのグループとして管理できます
• 自動修復機能により、障害が発生した VM を自動的に再作成できます

• MIG: メリット：高可用性、自動スケーリング、自動修復、デメリット：設定が複雑
• 単一 VM: メリット：シンプル、デメリット：可用性が低い

6.2 ヘルスチェックの作成

# ヘルスチェックの作成（MIGの自動修復に必要）
resource "google_compute_health_check" "nginx_health_check" {
  name               = "nginx-health-check"
  check_interval_sec = 10
  timeout_sec         = 5
  healthy_threshold  = 2
  unhealthy_threshold = 3

  http_health_check {
    port         = 80
    request_path = "/"
  }
}

6.3 ロードバランサーの作成

# バックエンドサービスの作成
resource "google_compute_backend_service" "nginx_backend" {
  name                  = "nginx-backend"
  protocol              = "HTTP"
  port_name             = "http"
  load_balancing_scheme = "EXTERNAL"
  timeout_sec           = 30

  backend {
    group = google_compute_instance_group_manager.nginx_group.instance_group
  }

  health_checks = [google_compute_health_check.nginx_health_check.id]
}

# グローバル転送ルールの作成（ロードバランサーのIPアドレスを公開）
resource "google_compute_global_forwarding_rule" "nginx_lb" {
  name       = "nginx-lb"
  target     = google_compute_backend_service.nginx_backend.id
  port_range = "80"
}

ステップ 7: VM Manager を使用したパッチ管理

7.1 OS Config API の有効化

# OS Config APIを有効化（VM Managerに必要）
gcloud services enable osconfig.googleapis.com --project=cookbook-251226

7.2 プロジェクトメタデータの設定

# プロジェクトメタデータを設定（VM Managerを有効化）
gcloud compute project-info add-metadata --metadata=enable-osconfig=TRUE --project=cookbook-251226
gcloud compute project-info add-metadata --metadata=enable-guest-attributes=TRUE --project=cookbook-251226

ステップ 8: Terraform の実行

8.1 Terraform の初期化

# Terraform用ディレクトリに移動
cd terraform

# Terraformの初期化
# このコマンドで、必要なプロバイダのプラグインがダウンロードされます
terraform init

8.2 実行プランの確認

# 実行プランの確認
# このコマンドで、作成・変更・削除されるリソースが表示されます
terraform plan

8.3 リソースの作成

# リソースの作成
# このコマンドで、定義したリソースが作成されます
terraform apply

8.4 リソースの確認

# 作成されたVMの一覧を表示
gcloud compute instances list --project=cookbook-251226

# 特定のVMの詳細を表示
gcloud compute instances describe linux-vm --zone=asia-northeast1-a --project=cookbook-251226

ステップ 9: リソースの削除

9.1 Terraform destroy の実行

# Terraform用ディレクトリに移動
cd terraform

# すべてのリソースを削除
# このコマンドで、Terraformで作成したすべてのリソースが削除されます
terraform destroy

• terraform destroyは、Terraform で作成したすべてのリソースを削除します
• 削除前に確認プロンプトが表示されるので、内容を確認してから承認してください

9.2 個別リソースの削除