By default, Google Cloud Compute Engine encrypts all data at rest. A customer-supplied encryption key (CSEK), if specified, encrypts the data encryption keys. Google does not store any CSEK on a Compute Engine instance and cannot access the protected data unless the correct CSEK is provided.

Example 1: The following example shows a Terraform Configuration that defines a persistent disk for a Compute Engine instance. The disk_encryption_key block is missing so there is no CSEK to protect the data encryption keys.

resource "google_compute_disk" "compute-disk-demo" {
    name  = "test-disk"
    type  = "pd-ssd"
}

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 block-project-ssh-keys to false in the metadata argument.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  metadata = {
    block-project-ssh-keys = false
    ...
  }
  ...
}

Failure to block unwanted network traffic expands a cloud service's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by malicious entities.

By default, the serial port of a Compute Engine instance is disabled for console access. Enabling serial console access can allow attackers to connect to the Compute Engine instance from any IP address because the serial port does not support IP-based access restrictions.

Example 1: The following Terraform configuration permits interactive serial console access by setting serial-port-enable to true in the metadata argument.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  metadata = {
    serial-port-enable = true
    ...
  }
  ...
}

Every cloud service security feature has a unique ability to prevent or mitigate a known threat. Any feature disabled by intent or mistake offers no protection.

Disabling any Shield VM option allows an attacker to bypass implemented security restrictions for a guest operating system on a Compute Engine instance. Recommended Shield VM options (and their corresponding Terraform configuration identifiers) are as follows:

- Integrity Monitoring (enable_integrity_monitoring)
- Secure Boot (enable_secure_boot)
- Virtual Trusted Platform Module (enable_vtpm)

Example 1: The following Terraform configuration sets enable_integrity_monitoring to false in the shielded_instance_config block. Not all recommended Shield VM options are enabled.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  shielded_instance_config {
    enable_integrity_monitoring = false
    enable_secure_boot = true
    enable_vtpm = true
  }
  ...
}

The GKE control plane makes global decisions about a cluster and by default, many of its API endpoints are publicly accessible. Adding authorized networks using an allow list can provide network level protection for control plane access.

Example 1: The following example Terraform configuration sets up a public cluster without defining any authorized networks in the master_authorized_networks_config block. As a result, the GKE control plane API endpoints are publicly accessible.

resource "google_container_cluster" "cluster_demo" {
  name = "name-demo"
}

By default, the certificate-based authentication is disabled on new clusters that run GKE version 1.12 and later. With certificate-based authentication, a user presents a certificate that the Kubernetes API server verifies with the specified certificate authority. However, there is no way to revoke the certificate when the user leaves or loses the credentials. This makes the certificate-based authentication unsuitable for end users.

Example 1: The following example Terraform configuration enables GKE client certificate-based authentication by setting issue_client_certificate to true in the master_auth block.

resource "google_container_cluster" "container_cluster_demo" {
...
  master_auth {
    client_certificate_config {
      issue_client_certificate = true
      ...
    }
    ...
  }
...
}

A Kubernetes API server, the central management entity of a cluster, accepts HTTP basic authentication to authenticate users. HTTP Basic Authentication is deprecated and susceptible to brute force attacks and exposes user credentials to attackers in a misconfigured environment.

Example 1: The following example shows a Terraform configuration that enables HTTP basic authentication on a GKE cluster by setting username and password to non-empty values in the master_auth block.

resource "google_container_cluster" "container_cluster_demo" {
...
  master_auth {
    username = "foo"
    password = "bar"
  }
...
}