My Title

[bridgecrew-dev]

Bridgecrew has created this PR to fix one or more resources in the infrastructure files of this project.

Changes included in this PR:

• /terraform/gcp/instances.tf:google_compute_instance.server

Below are the Policies fixed in this PR:

🌈 Policy	✨ Details
Ensure 'Block Project-wide SSH keys' is enabled for VM instances	View

Please check the changes in this PR to ensure they do not introduce conflicts to your project.

---

For more information:
View this repository's Supply Chain Graph👀

[bridgecrew-dev]

Bridgecrew has found errors in this PR ⬇️

[bridgecrew-dev]

  Ensure boot disks for instances use CSEKs
    Resource: google_compute_instance.server | Bridgecrew ID: BC_GCP_GENERAL_2 | Checkov ID: CKV_GCP_38

How to Fix

//Option 2
resource "google_compute_disk" "default" {
  name  = "test-disk"
  type  = "pd-ssd"
  zone  = "us-central1-a"
  image = "debian-8-jessie-v20170523"
  physical_block_size_bytes = 4096
+  disk_encryption_key {
+    raw_key = <raw key>
  or
+    kms_key_self_link = <key link>
    }
}

//Option 2
resource "google_compute_instance" "default" {
  name         = "test"
  machine_type = "n1-standard-1"
  zone         = "us-central1-a"
  boot_disk {
    disk_encryption_key_raw = <encryption key>
    }
}

Description

Customer-Supplied Encryption Keys (CSEK) are a feature in Google Cloud Storage and Google Compute Engine.
Google Compute Engine encrypts all data at rest by default.
Compute Engine handles and manages this encryption automatically, with no additional action required.
When you provide your own encryption keys Compute Engine uses your key to protect the Google-generated keys used to encrypt and decrypt your data.
Only users that provide the correct key can use resources protected by a customer-supplied encryption key.
Google does not store your keys on its servers and cannot access your protected data unless you provide the key.
If you forget or lose your key Google is unable to recover the key or to recover any data encrypted with that key.
To control and manage this encryption yourself, you must provide your own encryption keys.
We recommend you supply your own encryption keys for Google to use, at a minimum to encrypt boot disks for instances.
This helps protect the Google-generated keys used to encrypt and decrypt your data.

Benchmarks

• NIST-800-53 CA-3

[bridgecrew-dev]

  Ensure compute instances do not have public IPs
    Resource: google_compute_instance.server | Bridgecrew ID: BC_GCP_PUBLIC_2 | Checkov ID: CKV_GCP_40

How to Fix

resource "google_compute_instance" "example" {
  name         = "test"
  machine_type = "n1-standard-1"
  zone         = "us-central1-a"
  boot_disk {}
-  access_config {
    ...
    }
}

Description

To reduce your attack surface Compute instances should not have public IP addresses.
To minimize the instance's exposure to the internet configure instances behind load balancers.
We recommend you ensure compute instances are not configured to have external IP addresses.

Benchmarks

• NIST-800-53 CA-3, SC-7
• ISO27001 A.8.2.3
• CIS GCP V1.1 4.9

[bridgecrew-dev]

  Ensure project instance does not override the project setting enabling OSLogin
    Resource: google_compute_instance.server | Bridgecrew ID: BC_GCP_NETWORKING_10 | Checkov ID: CKV_GCP_34

How to Fix

//Option 1
resource "google_compute_project_metadata" "default" {
  metadata = {
+    enable-oslogin = true
  }
}

//Option 2
resource "google_compute_instance" "default" {
  name         = "test"
  machine_type = "n1-standard-1"
  zone         = "us-central1-a"
  boot_disk {}
  metadata = {
-     enable-oslogin = false
  }
}

Description

Enabling OSLogin ensures that SSH keys used to connect to instances are mapped with IAM users.
Revoking access to IAM user will revoke all the SSH keys associated with that particular user.
It facilitates centralized and automated SSH key pair management.
This is useful in handling cases such as response to compromised SSH key pairs and/or revocation of external/third-party/Vendor users.
We recommend you enable OSLogin to bind SSH certificates to IAM users and facilitates effective SSH certificate management.

[bridgecrew-dev]

  Ensure GCP VM instances have block project-wide SSH keys feature enabled
    Resource: google_compute_instance.server | Bridgecrew ID: BC_GCP_NETWORKING_8 | Checkov ID: CKV_GCP_32

How to Fix

resource "google_compute_instance" "default" {
  name         = "test"
  machine_type = "n1-standard-1"
  zone         = "us-central1-a"
  metadata = {
+     block-project-ssh-keys = true
  }
}

Description

Project-wide SSH keys are stored in Compute/Project-meta-data.
Project wide SSH keys can be used to login into all instances within a project.
Using project-wide SSH keys eases SSH key management.
If SSH keys are compromised, the potential security risk can impact all instances within a project.
We recommend you use Instance specific SSH keys instead of common/shared project-wide SSH key(s), to limit the attack surface should the SSH keys be compromised.

Benchmarks

• CIS GCP V1.1 4.3

[bridgecrew-dev]

  Ensure GCP VM instances do not have serial port access enabled
    Resource: google_compute_instance.server | Bridgecrew ID: BC_GCP_NETWORKING_11 | Checkov ID: CKV_GCP_35

How to Fix

resource "google_compute_instance" "default" {
  name         = "test"
  machine_type = "n1-standard-1"
  zone         = "us-central1-a"
  boot_disk {}
  metadata = {
-     serial-port-enable = true
  }
}

Description

Interacting with a serial port is often referred to as the serial console.
It is similar to using a terminal window: input and output is entirely in text mode with no graphical interface or mouse support.
If the interactive serial console on an instance is enabled, clients can attempt to connect to that instance from any IP address.
For security purposes interactive serial console support should be disabled.
A virtual machine instance has four virtual serial ports.
Interacting with a serial port is similar to using a terminal window: input and output is entirely in text mode with no graphical interface or mouse support.
The instance's BIOS operating system and other system-level entities write output to the serial ports and accept input, for example, commands and responses to prompts.
Typically, these system-level entities use the first serial port (port 1).
Serial port 1 is often referred to as the serial console.
The interactive serial console does not support IP-based access restrictions, for example, an IP whitelist.
If you enable the interactive serial console on an instance, clients can connect to that instance from any IP address.
This allows anybody with the correct SSH key, username, project ID, zone, and instance name to connect to that instance.
To stop this type of access interactive serial console support should be disabled.

Benchmarks

• CIS GCP V1.1 4.5