Secure your Compute Engine by blocking project-wide SSH keys

Best practice for handling SSH keys in Google Cloud
When using Compute Engine in Google Cloud, you might wonder what’s the best way to handle SSH keys for your Virtual Machines (VMs) ? We’ve got some questions from our customers. There are several ways to implement and store SSH keys in your Google Cloud environment, but you might wonder about the best way to do so. In this blog, we will share our best practices for Compute Engine.

The Risks of Project-Wide SSH Keys
While convenient for managing access across multiple instances, project-wide SSH keys pose significant security risks. Such keys allow access to every Compute Engine instance within a project, creating a single point of failure. In the event of a compromise, all instances become vulnerable, significantly elevating the potential for widespread security breaches.

Advocating for Instance-Specific SSH Keys
To mitigate these risks, we strongly advocate using instance-specific SSH keys. This approach ensures that access is segregated, significantly reducing the impact of a compromised key. It necessitates a shift away from project-wide SSH keys, requiring a more granular, instance-by-instance management strategy.

Implementing Enhanced Security Measures
Blocking project-wide SSH keys is essential for enhancing security. The implementation of this measure varies based on how you manage your Compute Engine resources — be it through the Google Cloud Console, CI/CD pipelines, or Terraform. We describe a few ways to implement the blocking of SSH keys to ensure that you can secure your environment effectively regardless of how you deploy your Cloud resource.

Key Takeaways

• Avoid project-wide SSH keys to limit security vulnerabilities.
• Adopt instance-specific SSH keys for finer control and reduced risk.
• Customize your approach based on your specific Google Cloud deployment strategy.

Applying these best practices can significantly improve the security posture of your Compute Engine instances and help you minimize the blast radius in your Google Cloud environment when an SSH key gets compromised.

Below we describe two ways of blocking project-wide SSH keys in Google Cloud

1. Blocking project-wide SSH key(s) using the Google Cloud Console
Navigate to Security -> VM access -> Block project-wide SSH keys

Use Terraform to prevent project-wide ssh key(s) in your future deployments
To prevent and block project-ssh keys in future deployments, we advise you to add the Terraform code (See example below) to your Terraform template for re-use by your engineers .

2. Block project-wide SSH keys with Terraform
The full terraform code is available here on Jorge’s Github repository.

resource "google_compute_instance" "awesomename" {
  name                      = var.compute_engine_instance_name
  zone                      = var.gcp_zone_primary
  machine_type              = "e2-highmem-8"
  tags                      = ["http", "https", "ping"]
  project                   = var.gcp_project_id
  can_ip_forward            = false
  allow_stopping_for_update = true

  #Primary local VPC network (NIC0)
  network_interface {
    network    = google_compute_network.vpc_network.id
    network_ip = google_compute_address.private_static_ip.address
    subnetwork = var.local_vpc_awesomename_subnet_name

    access_config {
      nat_ip = google_compute_address.public_static_ip.address
    }
  }

  boot_disk {
    initialize_params {
      image = "debian-12-bookworm-v2024021"
      type  = "pd-ssd"
      size  = "30"
    }
  }

  shielded_instance_config {
    enable_secure_boot          = true
    enable_vtpm                 = true
    enable_integrity_monitoring = true
  }

  #Define API scopes for GCE Service Account.
  service_account {
    email  = google_service_account.awesomename-sa-ce-env.email
    scopes = var.sa-ce-scopes
  }

  metadata = {
    block-project-ssh-keys = true
    enable-os-login        = true
    serial-port-enable     = false
  }
}

Enhancing Security in Your CI/CD Pipeline: Scanning for Compliance
Incorporating security measures directly into your CI/CD pipeline is a proactive step towards ensuring that your infrastructure as code (IaC) adheres to best practices. A key measure involves scanning your Terraform plan to verify that the metadata value block-project-ssh-keys is set to true, effectively preventing the use of project-wide SSH keys.

Utilizing Security Scanners
Tools such as Snyk and Aqua Security’s tfsec play a critical role in this process. These scanners integrate with your CI/CD pipeline to automatically review all pull requests for compliance with your defined security policies. If a Terraform configuration does not meet the required standards, these tools can halt the deployment process, ensuring that only secure configurations are applied.

Advanced Steps: Implementing Organization Policy Constraints
Beyond scanning and blocking in the CI/CD pipeline, there’s an opportunity to reinforce your security posture further. If you’re already familiar with Google Cloud’s Organization Policy Constraints, you’re well-positioned to explore Custom Org Policy Constraints. These allow for more granular control over your cloud resources, enabling you to effectively enforce specific security practices across your organization.

Actions to consider

1. Integrate Security Scanning Tools: Configure tools like Snyk or Aqua Security’s tfsec within your CI/CD pipeline to automatically scan for and alert for non-compliant Terraform configurations.
2. Review and Update Your CI/CD Practices: Ensure that your pipeline is set up to enforce the block-project-ssh-keys metadata value, securing your deployments from the outset.
3. Explore Custom Org Policy Constraints: Investigate how Custom Org Policy Constraints can provide an additional layer of security, offering tailored control over your cloud environment.

By embedding these security checks into your CI/CD pipeline and considering the broader application of Organization Policy Constraints, you can significantly enhance your defense against the misuse of project-wide SSH keys, leading to a more secure cloud infrastructure.

OS Login
Evaluating the OS Login feature, especially with two-factor authentication (2FA), for your Compute Engine instances could be beneficial. We plan to publish a future blog post detailing how to get the most out of OS Login.

Get started today with blocking project wide SSH keys
If you have any questions regarding this or other topics on Google Cloud, please feel free to contact Jorge or Lars. We are always willing to share our thoughts and experience!