We have started working on adding security issues to detect Google Cloud Platform (GCP) misconfigurations in your Terraform configuration files. This would help safeguard your infrastructure from various attack vectors by suggesting security best practices.
To get things started, we have added 10 new GCP issues to our Terraform analyzer. Here’s a detailed description of each of them.
TF-S2001: Ensure Stackdriver Logging is set to Enabled
on Kubernetes Engine Clusters
Stackdriver is the default logging solution for clusters deployed on GKE and should be enabled so that access can be audited.
TF-S2002: Ensure Google compute firewall ingress does not allow unrestricted SSH access
The firewall rules setup has allow
/deny
traffic policies to enforce and help protect instances from unwanted traffic consistently. default-allow-ssh
is a rule populated by default with firewall rules for a network that permits ingress connections on TCP port 22 from any source to any instance in the network, which opens up possibilities of attacks. It is highly recommended to restrict or remove the default-allow-ssh
rule when it is no longer required.
# Recommended
resource "google_compute_firewall" "default" {
name = "firewall-test"
network = google_compute_network.default.name
allow {
protocol = "icmp"
}
deny {
protocol = "ssh"
ports = ["22"]
}
TF-S2003: Ensure Google compute firewall ingress does not allow unrestricted RDP access
GCP Firewall rule allowing traffic on RDP (Remote Desktop Protocol) port 3389 should be avoided by either restricting or removing the default-allow-rdp
when it is no longer required. The default-allow-rdp
rule allows ingress connections to TCP destination port 3389 from any source to any instance in the network enabling connections to instances running the Microsoft Remote Desktop Protocol. It is highly recommended to restrict or remove the default-allow-rdp
rule when it is no longer required.
# Recommended
resource "google_compute_firewall" "default" {
name = "firewall-test"
network = google_compute_network.default.name
allow {
protocol = "icmp"
}
deny {
protocol = "tcp"
ports = ["3389"]
}
TF-S2004: Ensure no HTTPS or SSL proxy load balancers permit SSL policies with weak cipher suites
SSL policies control SSL features in Google Cloud SSL proxy load balancer and external HTTP(S) load balancers. By default, HTTP(S) Load Balancing and SSL Proxy Load Balancing use a set of SSL features that provides good security and broad compatibility.
We recommend our users opt from the following options to prevent usage of insecure features:
-
TLS (
min_tls_version
) should be set to1.2
with theMODERN
profile -
Use
RESTRICTED
profile as it effectively requires clients to useTLS 1.2
regardless of the chosen minimum TLS version -
Use a
CUSTOM
profile that does not use any of the following cipher suites:TLS_RSA_WITH_AES_128_GCM_SHA256
,TLS_RSA_WITH_AES_256_GCM_SHA384
,TLS_RSA_WITH_AES_128_CBC_SHA
,TLS_RSA_WITH_AES_256_CBC_SHA
,TLS_RSA_WITH_3DES_EDE_CBC_SHA
# Recommended practices:
# TLS 1.2 with the `MODERN` profile
resource "google_compute_ssl_policy" "modern-profile" {
name = "test-ssl-policy"
profile = "MODERN"
min_tls_version = "TLS_1_2"
}
# `RESTRICTED`
resource "google_compute_ssl_policy" "custom-profile" {
name = "test-ssl-policy"
profile = "RESTRICTED"
}
# Recommended
resource "google_compute_ssl_policy" "custom-profile" {
name = "test-ssl-policy"
profile = "CUSTOM"
min_tls_version = "TLS_1_2"
custom_features = ["TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384", "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"]
}
Related: https://www.terraform.io/docs/providers/google/r/compute_ssl_policy.html
TF-S2006: Ensure all Cloud SQL database instance requires all incoming connections to use SSL
Cloud SQL is a fully-managed database service that makes it easy to set up, maintain, manage and administer your relational MySQL databases on a Cloud Platform and we recommend enforcing all connections to use SSL/TLS when connecting with the Cloud SQL database instances to safeguard against attacks.
TF-S2007: Ensure Legacy Authorization is set to Disabled
on Kubernetes Engine Clusters
Attribute-Based Access Control (ABAC) permissions are less secure than Role-Based Access Control (RBAC) permissions, with advantages including granting permissions to resources at the cluster and namespace levels and allowing defining roles with rules containing a set of permissions.
We highly recommend moving away from legacy authorization with ABAC and switch to RBAC for more secure authorization for your infrastructure.
Related:
— https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#leave_abac_disabled
— https://www.terraform.io/docs/providers/google/r/container_cluster.html#enable_legacy_abac
TF-S2008: Ensure Stackdriver Monitoring is set to Enabled on Kubernetes Engine Clusters
We recommend keeping monitoring enabled for GKE to easily audit access, performance bottlenecks, usage, etc.
TF-S2009: Ensure ‘Automatic node repair’ is enabled for Kubernetes Clusters
It is highly recommended to ensure keeping this feature enabled as it provides continued operation of nodes by identifying and repairing failing nodes and ensures applications operate based on their pre-defined specs, minimized downstream failures, and redundant alerting and triage.
Related:
— https://www.terraform.io/docs/providers/google/r/container_node_pool.html
— https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-repair
TF-S2010: Ensure ‘Automatic node upgrade’ is enabled for Kubernetes Clusters
Node auto-upgrade keeps nodes up-to-date with the latest cluster master version when your master is updated on your behalf. We recommend keeping this feature enabled to ensure the latest security updates, bug fixes, etc., are being automatically applied.
Related: https://www.terraform.io/docs/providers/google/r/container_node_pool.html
TF-S2011: Ensure that Cloud SQL database instances are not open to the world
Cloud SQL database instances should not be publicly available to lower your infrastructure’s attack surface. We recommend, where possible, the usage of private IPs instead of public IPs, and segments should be broken into smaller subnets and avoid using the /0
subnet.