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 https://en.wikipedia.org/wiki/Principle_of_least_privilege[the principle of least privilege].
* Unlike managed access control with https://cloud.google.com/compute/docs/instances/managing-instance-access[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 https://cloud.google.com/compute/docs/instances/access-overview?_ga=2.125788746.-190863609.1642494607#oslogin[OSLogin] to benefit from managed access control.


== Sensitive Code Example
[source,terraform]
----
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
[source,terraform]
----
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

* https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/[OWASP Top 10 2021 Category A7] - Identification and Authentication Failures
* https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication.html[OWASP Top 10 2017 Category A2] - Broken Authentication
* https://cwe.mitre.org/data/definitions/266[MITRE, CWE-266] - Incorrect Privilege Assignment
* https://cwe.mitre.org/data/definitions/269[MITRE, CWE-269] - Improper Privilege Management
* https://cwe.mitre.org/data/definitions/272[MITRE, CWE-272] - Least Privilege Violation
* https://cloud.google.com/compute/docs/connect/restrict-ssh-keys#remove-metadata-key[GCP Documentation] - Restrict SSH keys from VMs
* https://cloud.google.com/compute/docs/instances/access-overview#risks[GCP Documentation] - Risks of manual key management


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Make sure that enabling project-wide SSH keys is safe here.


endif::env-github,rspecator-view[]