Pierre-Loup 770348d041
Avoid OWASP Top 10 security-standard mismatch between metadata and description links (RULEAPI-798) (#3537)
* Add check for security standard mismatch

* Fix security standard mismatches

* Fix Resources/Standards links for secrets rules

* Fix check

* Fix links and update security standard mapping

* Fix maintanability issue

* Apply review suggestions

* Apply suggestions from code review

Co-authored-by: Egon Okerman <egon.okerman@sonarsource.com>

* Fix typo

Co-authored-by: Egon Okerman <egon.okerman@sonarsource.com>

---------

Co-authored-by: Egon Okerman <egon.okerman@sonarsource.com>
2024-01-17 17:20:28 +01:00

84 lines
2.7 KiB
Plaintext

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
* CWE - https://cwe.mitre.org/data/definitions/266[CWE-266 - Incorrect Privilege Assignment]
* CWE - https://cwe.mitre.org/data/definitions/269[CWE-269 - Improper Privilege Management]
* CWE - https://cwe.mitre.org/data/definitions/272[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[]