如何在Terraform中使用项目级SSH密钥

Great question! Using project-level SSH keys in Terraform is a total game-changer for managing access across multiple VMs—no more attaching keys to every single instance individually. Let me walk you through how to set this up, using Google Cloud Platform (GCP) as an example (since it has native support for project-level SSH keys), but I’ll also touch on how this translates to other clouds.

1. What Are Project-Level SSH Keys, Anyway? #

Project-level SSH keys are stored at the cloud project level, rather than on individual instances. Any VM in the project that’s configured to inherit project metadata will automatically accept these keys for SSH access. This is perfect for teams where multiple users need access to all instances, or when you want a single source of truth for SSH access.

2. Configure Project-Level SSH Keys in Terraform #

For GCP, we’ll use the google_compute_project_metadata resource to add our SSH keys to the project’s metadata. Here’s a basic example:

# Define variables (you can set these in terraform.tfvars or via CLI)
variable "ssh_user" {
  type        = string
  description = "Username for SSH access"
  default     = "admin"
}

variable "ssh_public_key_path" {
  type        = string
  description = "Path to your public SSH key file"
  default     = "~/.ssh/id_rsa.pub"
}

# Add SSH key to project metadata
resource "google_compute_project_metadata" "project_ssh_keys" {
  metadata = {
    ssh-keys = "${var.ssh_user}:${file(var.ssh_public_key_path)}"
  }
}

If you need to add multiple SSH keys (for multiple users), just join them with newlines:

resource "google_compute_project_metadata" "project_ssh_keys" {
  metadata = {
    ssh-keys = join("\n", [
      "${var.ssh_user1}:${file(var.ssh_public_key_path1)}",
      "${var.ssh_user2}:${file(var.ssh_public_key_path2)}",
      # Add more keys as needed
    ])
  }
}

3. Ensure VMs Inherit Project Keys #

The key here is to not override the ssh-keys metadata field on individual instances. By default, GCP VMs inherit project-level metadata, so if you don’t define ssh-keys in your instance’s metadata, it will automatically use the project’s keys.

Here’s a sample VM configuration that inherits project-level SSH keys:

resource "google_compute_instance" "example_vm" {
  name         = "my-project-vm"
  machine_type = "e2-micro"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    network = "default"
    access_config {
      # Assign an ephemeral public IP
    }
  }

  # Important: Do NOT define `metadata = { ssh-keys = ... }` here
  # If you do, it will override the project-level keys
}

4. Verify Your Setup #

Once you’ve applied your Terraform configuration (terraform apply), test SSH access using your private key:

ssh -i ~/.ssh/id_rsa admin@<vm-public-ip>

You can also confirm the VM has inherited the project keys by checking its metadata:

gcloud compute instances describe my-project-vm --zone us-central1-a --format="value(metadata.items.ssh-keys)"

5. For Other Cloud Providers #

Not all clouds have native project-level SSH keys, but you can replicate the behavior:

• AWS: Use IAM Roles for SSH access (via EC2 Instance Connect) or store SSH keys in Secrets Manager, then pull them into instances via user data scripts.
• Azure: Use Azure AD for SSH access, or store keys in Azure Key Vault and inject them into VMs during deployment.

The core idea remains the same: centralize your SSH key management instead of attaching keys to each instance.

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