SSH keys stored and managed in a project’s metadata can be used to access GCP VM instances. By default, GCP automatically deploys project-level SSH keys to VM instances.

Project-level SSH keys can lead to unauthorized access because:

• Their use prevents fine-grained VM-level access control and makes it difficult to follow the principle of least privilege.
• Unlike managed access control with OS Login, manual cryptographic key management is error-prone and requires careful attention. For example, if a user leaves a project, their SSH keys should be removed from the metadata to prevent unwanted access.
• If a project-level SSH key is compromised, all VM instances may be compromised.

Ask Yourself Whether

• VM instances in a project have different security requirements.
• Many users with different profiles need access to the VM instances in that project.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Block project-level SSH keys by setting the metadata.block-project-ssh-keys argument to true
• Use OSLogin to benefit from managed access control.

Sensitive Code Example

resource "google_compute_instance" "example" { # Sensitive, because metadata.block-project-ssh-keys is not set to true
  name         = "example"
  machine_type = "e2-micro"
  zone         = "us-central1-a"

  network_interface {
    network = "default"

    access_config {
    }
  }
}

Compliant Solution

resource "google_compute_instance" "example" {
  name         = "example"
  machine_type = "e2-micro"
  zone         = "us-central1-a"

  metadata = {
    block-project-ssh-keys = true
  }

  network_interface {
    network = "default"

    access_config {
    }
  }
}

See

• CWE - CWE-266 - Incorrect Privilege Assignment
• CWE - CWE-269 - Improper Privilege Management
• CWE - CWE-272 - Least Privilege Violation
• GCP Documentation - Restrict SSH keys from VMs
• GCP Documentation - Risks of manual key management