Kingdom: Environment
This section includes everything that is outside of the source code but is still critical to the security of the product that is being created. Because the issues covered by this kingdom are not directly related to source code, we separated it from the rest of the kingdoms.
GCP Terraform Misconfiguration: Compute Engine Project-Wide SSH
Abstract
A Terraform configuration sets up a Compute Engine instance without blocking project-wide SSH login.
Explanation
By default, you can use SSH keys stored in project metadata to access all Compute Engine instances in a project. This greatly expands the attack surface accessible to any compromised SSH key and violates the least privilege principle.
Example 1: The following example shows a Terraform configuration that permits project-wide SSH logins by setting
Example 1: The following example shows a Terraform configuration that permits project-wide SSH logins by setting
block-project-ssh-keys to false in the metadata argument.
resource "google_compute_instance" "compute_instance_demo" {
...
metadata = {
block-project-ssh-keys = false
...
}
...
}
References
[1] HashiCorp google_compute_instance
[2] Google Cloud Restrict SSH keys from VMs
[3] Standards Mapping - CIS Google Cloud Computing Platform Benchmark Recommendation 4.3
[4] Standards Mapping - Common Weakness Enumeration CWE ID 250
[5] Standards Mapping - Common Weakness Enumeration Top 25 2024 [15] CWE ID 269
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000381, CCI-002233, CCI-002235
[7] Standards Mapping - FIPS200 AC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-6 Least Privilege (P1), CM-7 Least Functionality (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-6 Least Privilege, CM-7 Least Functionality
[11] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.4 General Access Control Design (L1 L2 L3)
[13] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[14] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 7.1.2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 7.2.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 7.2.2
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[21] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
desc.structural.hcl.gcp_terraform_misconfiguration_compute_engine_project_wide_ssh