Insecure authentication method - Basic

Need

Secure authentication method

Context

Usage of Terraform for Infrastructure as Code (IaC)
Usage of azurerm for managing resources in Azure

Description

Non compliant code

provider "azurerm" {
  features {}
  subscription_id = "your_subscription_id"
  client_id       = "your_client_id"
  client_secret   = "your_client_secret"
  tenant_id       = "your_tenant_id"
}

This code is vulnerable because it uses Basic authentication method, which is insecure. Here, the Terraform provider for Azure (azurerm) is configured using static values for subscription_id, client_id, client_secret, and tenant_id.

These values are sensitive and should not be hardcoded into the Terraform configuration file. If this file is committed to a public repository, these secrets will be exposed to anyone who can access the repository, leading to potential unauthorized access to the Azure resources.

Moreover, the communication channel is insecure which makes it vulnerable to Man-in-the-Middle (MitM) attacks. In such attacks, an attacker intercepts the communication, gaining access to the sensitive information.

Solution

You should use a secure authentication method and secure communication channel. You can store these secrets in Azure Key Vault and retrieve them in your Terraform configuration.

data "azurerm_key_vault_secret" "client_id" {
  name         = "client-id"
  key_vault_id = data.azurerm_key_vault.main.id
}

data "azurerm_key_vault_secret" "client_secret" {
  name         = "client-secret"
  key_vault_id = data.azurerm_key_vault.main.id
}

provider "azurerm" {
  features {}
  subscription_id = "your_subscription_id"
  client_id       = data.azurerm_key_vault_secret.client_id.value
  client_secret   = data.azurerm_key_vault_secret.client_secret.value
  tenant_id       = "your_tenant_id"
}

In this solution, client_id and client_secret are stored in Azure Key Vault and retrieved dynamically in the Terraform configuration. This way, the sensitive data is not exposed in the configuration file.

Steps

1. Remove the 'client_id', 'client_secret', and 'tenant_id' values from the code.
1. Implement a more secure authentication mechanism like Bearer or OAuth.
1. Store the sensitive authentication information securely, such as in Azure Key Vault.
1. Update the code to retrieve the authentication information from the secure storage instead of hardcoding it.

Compliant code

provider "azurerm" {
  features {}
  subscription_id = "your_subscription_id"
}

data "azurerm_client_config" "current" {}

data "azuread_service_principal" "example" {
  application_id = data.azurerm_client_config.current.client_id
}

data "azurerm_key_vault_secret" "example" {
  name         = "client-secret"
  key_vault_id = data.azurerm_key_vault.example.id
}

The updated code removes the 'client_id', 'client_secret', and 'tenant_id' values from the provider block. Instead, it uses the 'azurerm_client_config' data source to automatically fetch the 'client_id' and 'tenant_id' from the Azure provider's configuration.

The 'client_secret' is stored securely in an Azure Key Vault and retrieved using the 'azurerm_key_vault_secret' data source. This ensures that the 'client_secret' is not exposed in the Terraform code, providing a more secure authentication method.

This approach adheres to best practices for managing sensitive data in Terraform and helps to prevent potential security vulnerabilities associated with insecure authentication methods.

References

015.Insecure authentication method - Basic

Need​

Context​

Description​

Non compliant code​