25 new issues added to the Terraform Analyzer

New in DeepSource
,
1

We have recently updated our Terraform Analyzer with 25 more issues targeting security in Google Cloud Platform and Azure.

With this update, the analyzer can now detect a total of 155 issues in your Terraform configuration files. Check out its detecting capabilities here.

Here are some of the recently added issues:

TF-S1001: Azure instance is using basic authentication

SSH is an encrypted connection protocol that allows secure sign-ins over unsecured connections, and it is also the default connection protocol for Linux VMs hosted on Azure. We recommend connecting to a VM using SSH keys. Using basic authentication leaves VMs vulnerable to brute-force attacks or methods of password extraction.

// Recommended
resource "azure_vm_linux" "example" {
  ...
admin_ssh_key {
    username   = "admin"
    public_key = file("~/.ssh/id_rsa.pub")
}

TF-S1003: enable_https_traffic_only is not set to true

When the secure transfer is needed, a call to an Azure Storage REST API operation must be made over HTTPS because requests made over HTTP get rejected.

Thus, we recommend configuring Azure Blob storage to accept requests from secure connections only which can be done.

// Recommended
resource "azure_storage_account" "example" {
  ...
  enable_https_traffic_only = true
}

TF-S1005: Azure AKS is not using RBAC

AKS (Azure Kubernetes Service) can be configured to use Azure AD (Active Directory) and Kubernetes RBAC (Role-based Access Control). RBAC is recommended as it is designed to work on resources within your AKS clusters. With that you can define roles that outlines the permissions to be applied and gives more granular control.

// Bad practice
resource "azurerm_k8_cluster" "example" {
	role_based_access_control {
		enabled = false
	}
}

// Recommended
resource "azure_k8_cluster" "example" {
	role_based_access_control {
		enabled = true
	}
}

TF-S1013: App Service Authentication is not enabled on Azure App Service

Azure App Service Authentication is a feature that prevents anonymous HTTP requests from reaching the application. Authentication of users is handled for providers like Azure Active Directory, Google, Meta, Microsoft Account, and Twitter. Also, it does validation authentication, storing and refreshing tokens, managing the authenticated sessions, and injecting identity information into request headers and hence recommended to enable this feature.

TF-S1014: Web application does not redirect all HTTP traffic to HTTPS in Azure App Service

Azure App Service, by default, allows sites to run under both HTTP and HTTPS, but one should avoid accepting non-secure HTTP requests. HTTPS uses the SSL/TLS protocol to provide encrypted and authenticated connections, whereas HTTP does not. Hence, it is recommended to enforce HTTPS-only traffic by redirecting all non-secure HTTP requests to the HTTPS port to increase security.

TF-S1019: Standard pricing tier is not selected

The “standard” tier in Azure’s Security Center enables threat detection for networks and virtual machines. It allows greater (compared to “free” tier) in-depth defense like threat detection for networks and virtual machines, providing threat intelligence, anomaly detection, and behavior analytics. It is highly recommended to opt for the “standard” tier instead of the “free” tier.

// Bad practice
resource "azurerm_security_center_subscription_pricing" "xyz" {
    tier = "Free"
}

// Recommended
resource "azurerm_security_center_subscription_pricing" "xyz" {
    tier = "Standard"
}

TF-S2013: Kubernetes Engine Cluster authentication missing client certificate (GCP)

Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to authenticate API requests through authentication plugins. If a client certificate is presented and verified, the subject’s common name is used as the user name for the request. It can also indicate a user’s group memberships using the certificate’s organization fields and hence recommended to use client certificates.

// Recommended
master_auth {
  client_certificate_config {
    issue_client_certificate = true
  }
}

Reference: https://www.terraform.io/docs/providers/google/r/container_cluster.html#client_certificate_config

TF-S2015: Exposed BigQuery datasets (GCP)

The allAuthenticatedUsers option gives all account holders access to the dataset and makes the dataset public. Dataset-level permissions help determine which users, groups, and service accounts can access tables, views, and table data in a specific BigQuery dataset.


// Bad practice
resource "google_bigquery_dataset" "dataset" {
    dataset_id                  = "example_dataset"
    ...
    access {
        special_group = "allAuthenticatedUsers"
        role          = "OWNER"
        user_by_email = google_service_account.bqowner.email
    }
}

// Recommended
resource "google_bigquery_dataset" "dataset" {
    dataset_id                  = "example_dataset"
    ...
    access {
        role          = "OWNER"
        user_by_email = google_service_account.bqowner.email
    }
}

TF-S2017: Found usage of RSASHA1 for the zone-signing and key-signing keys in Cloud DNS DNSSEC (GCP)

DNSSEC is a DNS (Domain Name System) feature that authenticates responses to domain name lookups and supports advanced configurations if it is enabled for your managed zones. These include denial of existence, unique signing algorithms, and the ability to use record types that require or recommend DNSSEC for their use.

RSASHA1 is not recommended for the zone-signing and key-signing keys in Cloud DNS DNSSEC unless required for compatibility reasons as there is no security advantage to using it with larger key lengths.

// Bad practice
resource "google_dns_managed_zone" "foo" {
  name     = "foobar"
  dns_name = "foo.bar."
  zone_signing_keys {
    algorithm = "rsasha1"
  }
}

// Recommended
resource "google_dns_managed_zone" "foo" {
  name     = "foobar"
  dns_name = "foo.bar."
  zone_signing_keys {
  }
}