If a Compute Engine instance is created without a user-managed service account specification, Google Cloud assigns a default service account to the instance. The access rights of the default service account are often beyond what the instance needs to operate. This violates the least privilege principle.

Example 1: The following example shows a Terraform configuration that creates a Compute Engine instance without a user-managed service account specification. The service_account block is missing.

resource "google_compute_instance" "instance-demo" {
    name = "name-demo"
    machine_type = "e2-micro"
    boot_disk {
    ...
    }
    network_interface {
    ...
    }
}

Failure to block unwanted network traffic expands a cloud service's attack surface.

By default, IP forwarding is disabled in a Compute Engine instance. IP forwarding allows sending and receiving packets with non-matching source or destination IPs. An attacker can exploit this by routing packets through the Compute Engine instance to bypass network access control.

Example 1: The following Terraform configuration enables IP forwarding by setting can_ip_forward to true.

resource "google_compute_instance" "compute_instance_demo" {
  ...
  can_ip_forward = true
  ...
}

By default, a Compute Engine instance is not a Confidential VM. A Confidential VM uses hardware-based cryptography for data-in-use protection and to support remote attestations. Non-exportable dedicated per-VM instance keys keep VM memory encrypted, thereby protecting VM confidentiality and integrity against cloud provider access via the higher-privileged hypervisor.

Example 1: The following example shows a Terraform configuration that disables Confidential VM by setting enable_confidential_compute to false.

resource "google_compute_instance" "default" {
  ...
  confidential_instance_config {
    enable_confidential_compute = false
  }
  ...
}

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
  }
  ...
}

By default, Edge Cache services accept unencrypted and unsecured connections. These connections expose data to unauthorized access, potential theft, and tampering.

Example 1: The following example shows a Terraform configuration that defines an Edge Cache Service that allows clients to use HTTP for communication by setting https_redirect to false.

resource "google_network_services_edge_cache_service" "srv_demo" {
...
  routing {
...
    path_matcher {
...
      route_rule {
...
        url_redirect {
          https_redirect = false
        }
      }
    }
  }
}

Customer-managed encryption keys (CMEK) are not enabled for data at rest.

By default, Google Cloud uses randomly generated Data Encryption Keys (DEK) to encrypt data at rest. The CMEK feature allows organizations to use cryptographic keys of their choice to encrypt DEK. This gives organizations better control over and logging of encryption processes.

As such, CMEK is often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys
- Tamper-resistant hardware security module

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"
  }
...
}

By default, Attribute-Based Access Control (ABAC) is disabled on new clusters that run GKE version 1.8 and later. ABAC can statically grant a specific user or a group access to a resource in addition to those provided by Role-Based Access Control (RBAC) or Identity and Access Management (IAM). This complicates authorization administration and undermines the centralized access control.

Example 1: The following example shows a Terraform configuration that enables legacy ABAC authorization on a GKE cluster by setting enable_legacy_abac to true.

resource "google_container_cluster" "container_cluster_demo" {
...
  enable_legacy_abac = true
...
}

Every cloud service security feature is designed to prevent or mitigate a known threat. When disabled by intent or negligence, it offers no protection.

By default, if a GKE node repeatedly reports an unhealthy status over a given period, GKE initiates a repair process for that node. Disabling node auto-repair prevents timely and automated replacements of unhealthy nodes on which mission-critical workloads might run.

Example 1: The following Terraform configuration disables node auto-repair of a node pool by setting auto_repair to false in the management block.

resource "google_container_node_pool" "node-pool-demo" {
...
  management {
    auto_repair = 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.

Private GKE nodes do not have external IP addresses. Pods that run on these nodes cannot communicate beyond the cluster perimeter. Disabling a public endpoint protects the GKE cluster by limiting its management to internal private IP addresses. Failure to enforce a private endpoint and private nodes exposes the cluster to the public.

Example 1: The following Terraform configuration permits any public IP address to access cluster nodes and the control plane because enable_private_nodes and enable_private_endpoint are set to false.

resource "google_container_cluster" "cluster-demo" {
...
  private_cluster_config {
    enable_private_endpoint = false
    enable_private_nodes = false
  }
...
}

By default, GKE nodes run with Container-Optimized OS (COS). COS is an operating system image that is optimized to run GKE nodes on Google Compute Engine instances. Opting out of the default forgoes the benefits of enhanced security and efficiency.

Example 1: The following example Terraform configuration sets up a pool of GKE nodes that do not run COS because image_type is set to a non-COS image in the node_config block.

resource "google_container_node_pool" "node_pool_demo" {
  ...
  node_config {
    image_type = "UBUNTU"
    ...
  }
  ...
}

By default, GKE automatically upgrades Kubernetes nodes to newer stable versions. Automatic upgrades, which ensure timely patching of known software vulnerabilities, are disabled.

Example 1: The following example Terraform configuration disables automatic upgrades of Kubernetes nodes by setting auto_upgrade to false in the management block.

resource "google_container_node_pool" "node_pool_demo" {
...
  management {
    auto_upgrade = false
    ...
  }
...
}

By default, a new Google Cloud project starts with a project-wide network. The default network is pre-populated with firewall rules that permit unrestricted communication among Compute Engine instances in the same project and expose security sensitive ports of all instances to the public. The affected ports include TCP 22 (SSH) and TCP 3389 (RDP). Any insufficiently protected instance is susceptible to unauthorized access.

Example 1: The following example Terraform configuration enables the auto-creation of a project-wide network by setting auto_create_network to true.

resource "google_project" "project-demo" {
...
  auto_create_network = true
...
}

The Terraform configuration sets the access scope of a service account to cloud-platform, which allows access to most of the Google Cloud APIs. This greatly expands the attack surface accessible to any compromised Compute Engine instance and violates the least privilege principle.

Example 1: The following example shows a Terraform configuration that sets the access scope (scopes) of the service account to cloud-platform.

resource "google_compute_instance" "compute-instance-demo" {
    name         = "name-demo"
    machine_type = "e2-micro"
    ...
    service_account {
        email  = "foobar.service.account@example.com"
        scopes = ["cloud-platform"]
    }
}

By default, the domain for an App Engine application accepts unencrypted and unsecured connections. These connections expose data to unauthorized access, potential theft, and tampering.

Example 1: The following example shows a Terraform configuration that does not contain an ssl_settings block for the domain named example.com. As a result, the custom domain for the App Engine application does not support HTTPS.

resource "google_app_engine_domain_mapping" "domain_mapping" {
  domain_name = "example.com"
}