Before we define the Azure Terraform provider, let’s understand what makes a Terraform root module. The Terraform root module is just a working directory within your filesystem containing one or more .tf files that help you define your configuration and are where you would typically run your Terraform commands.
Terraform scans all your .tf files, combines them, and processes them internally as one. Therefore, you can have one or more .tf files that you can split according to your needs. While there are no defined standards for naming .tf files, most conventions use main.tf as the main Terraform file where they define resources, a vars.tf file for defining variables, and outputs.tf for defining outputs.
For this discussion, let’s create a main.tf file within our working directory and add a provider configuration like the following:
terraform {
required_providers {
azurerm = {
source = “azurerm”
version = “=3.55.0”
}
}
}
provider “azurerm” {
subscription_id = var.subscription_id
client_id = var.client_id
client_secret = var.client_secret
tenant_id = var.tenant_id
features {}
}
The preceding file contains two blocks. The terraform block contains the required_providers block, which declares the version constraint for the azurerm provider. The provider block
declares an azurerm provider, which requires four parameters.
Tip
Always constrain the provider version, as providers are released without notice, and if you don’t include the version number, something that works on your machine might not work on someone else’s machine or the CI/CD pipeline. Using a version constraint avoids breaking changes and keeps you in control.
You might have noticed that we have declared several variables within the preceding file instead of
directly inputting the values. There are two main reasons for that – we want to make our template as generic as possible to promote reuse. So, suppose we want to apply a similar configuration in another subscription or use another service principal; we should be able to change it by changing the variable values. Secondly, we don’t want to check client_id and client_secret in source control. It
is a bad practice as we expose our service principal to users beyond those who need to know about it.
Tip
Never store sensitive data in source control. Instead, use a tfvars file to manage sensitive information and keep it in a secret management system such as HashiCorp’s Vault.
Okay, so as we’ve defined the provider resource and the attribute values are sourced from variables, the next step would be to declare variables. Let’s have a look at that now.
