Terraform部署GCP VM时安全执行脚本的方案咨询

Hey there! Let's break down how to securely run scripts on GCP VMs with Terraform while keeping your scripts out of prying eyes, addressing all the pain points you mentioned:

1. Use Signed URLs for Startup Scripts (No Permanent Service Account Required) #

Instead of embedding plaintext scripts in metadata or binding a service account to the VM, you can generate time-limited signed URLs for your script stored in Cloud Storage. The VM will use this temporary URL to pull the script on startup, and the URL expires after your specified window—no permanent permissions needed.

How to Implement: #

1. Upload your script to a private Cloud Storage bucket.
2. Use Terraform's google_storage_object_signed_url data source to generate a short-lived signed URL.
3. Pass this URL as the startup-script-url metadata value for your VM.

Example Code:

# Upload your script to a private bucket
resource "google_storage_bucket_object" "setup_script" {
  name   = "secure-setup.ps1"
  bucket = "my-private-script-bucket"
  source = "./local-secure-script.ps1"
}

# Generate a 1-hour signed URL for the script
data "google_storage_object_signed_url" "script_url" {
  bucket       = google_storage_bucket_object.setup_script.bucket
  path         = google_storage_bucket_object.setup_script.name
  content_type = "application/octet-stream"
  expiration   = "3600" # URL expires after 1 hour

  depends_on = [google_storage_bucket_object.setup_script]
}

# Create VM with the signed URL as startup script source
resource "google_compute_instance" "windows_vm" {
  name         = "secure-vm"
  machine_type = "n1-standard-1"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "windows-server-2022-dc-v20240312"
    }
  }

  network_interface {
    network = "default"
    access_config {}
  }

  metadata = {
    startup-script-url = data.google_storage_object_signed_url.script_url.signed_url
  }
}

Why This Works: #

• The script stays private in Cloud Storage—only the temporary signed URL grants access.
• No need to bind a service account to the VM; the URL itself includes the necessary permissions.
• After expiration, the URL becomes useless, so even if someone gets ahold of it later, they can't access the script.

2. Automate Remote-Exec for Windows VMs (No Manual Password Setup) #

You're right that manual password setup for Windows VMs breaks Terraform's automation—but you can generate and set the initial password entirely in Terraform using the random_password resource and GCP's windows-initial-password metadata field. This lets you use remote-exec without touching the GCP Console.

How to Implement: #

1. Generate a secure random password with Terraform.
2. Pass the password to the VM's windows-initial-password metadata to set the Administrator account password on creation.
3. Use remote-exec with WinRM to run your script directly from your Terraform environment (no need to store the script in GCP at all).

Example Code:

# Generate a secure random password for the Windows VM
resource "random_password" "windows_admin_pass" {
  length           = 16
  special          = true
  override_special = "!@#$%^&*()"
}

# Create Windows VM with auto-set password
resource "google_compute_instance" "windows_vm" {
  name         = "remote-exec-vm"
  machine_type = "n1-standard-1"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "windows-server-2022-dc-v20240312"
    }
  }

  network_interface {
    network = "default"
    access_config {}
  }

  metadata = {
    windows-initial-password = random_password.windows_admin_pass.result
  }

  # Run script directly via WinRM
  provisioner "remote-exec" {
    inline = [
      "powershell.exe -Command \"Install-WindowsFeature -Name Web-Server\"",
      # Add your secure script commands here—they never leave your Terraform environment
    ]

    connection {
      type     = "winrm"
      user     = "Administrator"
      password = random_password.windows_admin_pass.result
      host     = self.network_interface[0].access_config[0].nat_ip
      port     = 5986
      https    = true
      insecure = true # For initial setup; use a custom certificate in production for better security
    }
  }
}

Why This Works: #

• The password is generated and set automatically—no manual Console steps needed.
• Your script runs directly from your Terraform machine to the VM; it's never stored in GCP metadata or storage, so no one with VM access can retrieve it.

3. Cloud Build for Isolated Script Execution (Strict Permission Controls) #

If you need even tighter isolation, use Cloud Build to execute your script on the VM. Cloud Build uses a temporary service account to connect to the VM, runs the script, and then revokes access automatically. Your script can be stored in a private Cloud Source Repository or encrypted storage, and only Cloud Build has access.

High-Level Steps: #

1. Create a Cloud Build trigger that runs your script (stored privately).
2. Grant Cloud Build the roles/compute.instanceAdmin.v1 permission to access the VM.
3. Use Terraform to trigger the Cloud Build job after VM creation.

This approach adds an extra layer of auditing and permission separation—users with VM access can't see or modify the script, as execution is handled by Cloud Build.

• Startup scripts with signed URLs: Best for scripts that need to run on VM boot, with minimal setup.
• Remote-exec with auto-generated password: Ideal for post-creation configuration where you want full control over script delivery.
• Cloud Build: Perfect for enterprise-grade security with strict audit and permission requirements.

内容的提问来源于stack exchange，提问作者Michi