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

By default, an HTTP trigger enables a Cloud Function to run in response to HTTPS requests only. Allowing insecure HTTP requests exposes data to unauthorized access, potential theft, and tampering.

Example 1: The following example shows a Terraform configuration that defines an HTTP trigger that fails to enforce HTTPS endpoints by setting https_trigger_security_level to SECURE_OPTIONAL.

resource "google_cloudfunctions_function" "demo_function" {
...
  trigger_http = true
  https_trigger_security_level = "SECURE_OPTIONAL"
...
}

By default, a Cloud SQL instance 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 require a database instance to enforce SSL for all connections by setting require_ssl to false.

resource "google_sql_database_instance" "database_instance_demo" {
  ...
  settings {
    ip_configuration {
      require_ssl = false
      ...
    }
    ...
  }
}

By default, an Edge Cache service 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 defines an Edge Cache service that does not require clients to use TLS for communication by setting require_tls to false.

resource "google_network_services_edge_cache_service" "srv_demo" {
...
  require_tls = false
...
}

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions that result in periodic version updates. Each new revision addresses security weaknesses discovered in the previous version. Use of an insecure version of TLS/SSL weakens the data protection and might allow an attacker to compromise, steal, or modify sensitive information.

Insecure versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing

The presence of these properties might enable an attacker to intercept, modify, or tamper with sensitive data.

Example 1: The following example Terraform configuration defines an SSL policy that permits the proxy load balancer to allow the use of weak SSL cipher suites by setting profile to COMPATIBLE.

resource "google_compute_ssl_policy" "policy-demo" {
...
  profile = "COMPATIBLE"
...
}

Example 2: The following example Terraform configuration that defines a custom SSL policy that specifically permits the proxy load balancer to allow the use of a weak SSL cipher suite named TLS_RSA_WITH_AES_128_CBC_SHA.

resource "google_compute_ssl_policy" "policy-demo" {
...
  profile = "CUSTOM"
  min_tls_version = "TLS_1_2"
  custom_features = ["TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256", "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_RSA_WITH_AES_128_CBC_SHA"]
...
}

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

A Terraform configuration creates a Cloud Storage Bucket without enabling usage and storage logs. These logs contain valuable data for network monitoring, forensics, real-time security analysis, and expense optimization.

Example 1: The following example shows a Terraform configuration that creates a Cloud Storage Bucket without enabling usage and storage logging because the log_bucket argument is missing.

resource "google_storage_bucket" "bucket-demo" {
    name     = "name-demo"
    location = "US"
}

By default, a Google Kubernetes Engine (GKE) cluster writes logs to the Stackdriver Kubernetes Engine Logging Service. The Terraform configuration sets up a GKE cluster and explicitly disables the logging service. Logs contain valuable data used to identify security incidents, monitor policy violations, and assist with non-repudiation controls.

Example 1: The following example shows a Terraform configuration that disables the logging service of a GKE cluster by setting logging_service to none.

resource "google_container_cluster" "cluster-demo" {
    name            = "name-demo"
    location        = "us-central1-a"
    logging_service = "none"
    ...
}

By default, a Google Kubernetes Engine (GKE) cluster sends metrics from Pods to the Stackdriver Kubernetes Engine Monitoring Service. The Terraform script sets up a GKE cluster and explicitly disables the monitoring service. The absence of metrics undermines proper detection of and prompt response to security events.

Example 1: The following example shows a Terraform configuration that disables the monitoring service of a GKE cluster by setting monitoring_service to none.

resource "google_container_cluster" "cluster-demo" {
    name               = "name-demo"
    location           = "us-central1-a"
    monitoring_service = "none"
    ...
}

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

The Terraform configuration sets up a Virtual Machine subnet without specifying logging options. These logs contain valuable data for network monitoring, forensics, real-time security analysis, and expense optimization.

Mismanagement of permissions increases the risk of unauthorized access to or modification of data and undermines service availability.

A service account is a special Google account used by an application or a VM instead of a person, which uses sensitive permissions to run automated processes or make API requests on behalf of end users. It should be carefully managed, controlled, and audited, so it can be trusted. Assigning a service account role to an IAM user, which typically represents a person, weakens the security control.

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.

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

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

A URL map is a set of rules to route incoming HTTP(S) requests to specific backend services. By default, a URL map 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 defines a URL map that allows clients to use HTTP for communication by setting https_redirect to false.

resource "google_compute_url_map" "urlmap" {
...
  default_url_redirect {
...
    https_redirect = false
...
  }
...
}

DNSSEC prevents DNS spoofing by providing the ability to use digital signatures for DNS response validation. Any DNSSEC signing algorithm that uses SHA-1, however, is susceptible to an ever-growing risk of attack. SHA-1 is no longer considered a secure hash algorithm when used with digital signatures.

Example 1: The following example shows a Terraform configuration that enables the DNSSEC with the insecure signing algorithm rsasha1.

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    default_key_specs {
      algorithm = "rsasha1"
      ...
    }
  }
...
}

GKE supports two cluster network modes: routes-based and VPC-native. VPC-native clusters use alias IP address ranges to route traffic from one Pod in a node to another Pod. This allows precise IP-based policies and firewall rules for Pods. In contrast, an entire node is the finest granularity level of control in routes-based clusters.

Example 1: The following example Terraform configuration does not enable a VPC-native cluster by setting networking_mode to ROUTES.

resource "google_container_cluster" "cluster_demo" {
...
  networking_mode = "ROUTES"
..
}