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

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

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

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

Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

Although this type of off-by-one error is still common on some platforms and in some development communities, there are a variety of other types of buffer overflow, including stack and heap buffer overflows among others. There are a number of excellent books that provide detailed information on how buffer overflow attacks work, including Building Secure Software [1], Writing Secure Code [2], and The Shellcoder's Handbook [3].

At the code level, buffer overflow vulnerabilities usually involve the violation of a programmer's assumptions. Many memory manipulation functions in C and C++ do not perform bounds checking and can easily exceed the allocated bounds of the buffers they operate upon. Even bounded functions, such as strncpy(), can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.

In this case, the program reads from outside the bounds of allocated memory, which can allow access to sensitive information, introduce incorrect behavior, or cause the program to crash.

Example: The following code sequentially dereferences five-element array of char, with the last reference introducing an off-by-one error.

char Read() {

char buf[5];
return 0
        + buf[0]
        + buf[1]
        + buf[2]
        + buf[3]
        + buf[4]
        + buf[5];
}