Insecure authentication method - Basic - Azure

Insecure authentication method - Basic - Azure

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.
  • 2. Implement a more secure authentication mechanism like Bearer or OAuth.
  • 3. Store the sensitive authentication information securely, such as in Azure Key Vault.
  • 4. 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