
* 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>
84 lines
2.7 KiB
Plaintext
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[]
|