Mastering Azure Infrastructure with Terraform

What is Terraform?

Terraform is an infrastructure tool for Building, changing, and Versioning infrastructure. Often referred to as Infrastructure as Code for . It is released by the HashiCorp organization.

It works with two coding data languages:

• HashiCorp Config Language (HCL)
• JSON

What is Terraform used for?

In its simplest form, Terraform can be used to automatically create server infrastructure on several different platforms. It can also be integrated into Continuous Integration and Continuous Delivery (CI/CD).

Terraform is a cloud-agnostic platform and is popular for the following cloud platforms :

• The Google Cloud Platform (GCP)
• Amazon Web Services (AWS)
• Microsoft Azure
• VMware
• Red Hat OpenStack

The Terraform Azure CLI

Terraform is baked into the Azure CLI. You can run it straight from the console or you can run it from Azure DevOps. There is no need to install Terraform, it is already there for you to use.

Everything Terraform does is controlled by the state file. No matter what you want to do, get the Terraform state up and running in a cloud bucket.

Simply open up a BASH or POWERSHELL cloud shell to access the program. Throughout this example, I will be using BASH

How to configure a Terraform Remote State

To ensure this works, you need to make sure you have the correct permissions

Create a new main.tf config file

vim main.tf

Copy this code into your main.tf file, ensuring you save and quit. This code will:

• Set Azure as the main provider
• Create your new terraform storage blob (please ensure you have a resource group created previously)
• Create a container inside the blob storage
• Create terraform.tfstate file

Make sure you update relevent to your settings

provider "azurerm" {
version = "2.0.0"
features {}
}
resource "azurerm_storage_account" "dev" {
  name                     = "YOUR BLOB NAME"
  resource_group_name      = "YOUR RESOURCE GROUP NAME"
  location                 = "UK South"
  account_tier            = "Standard"
  account_replication_type = "RAGRS"

   tags = {
    environment = "Terraform Storage"
    CreatedBy = "Rich Bailey"
}
resource "azurerm_storage_container" "dev" {
  name                  = "statefile"
  storage_account_name  = "YOUR BLOB NAME"
  container_access_type = "private"
}
}
terraform {
  backend "azurerm" {
    resource_group_name = "YOUR RESOURCE GROUP NAME"
    storage_account_name = "YOUR BLOB NAME"
    container_name = "statefile"
    key = "terraform.tfstate"
}
}

Now type:

terraform init

If everything is successful, you will see

Next type

terraform plan

this will check your code to make sure it’s accurate.

Now type

terraform apply

Check your Azure Blob storage to ensure that the Terraform state file has been uploaded. You can now share this bucket and the main.tf file with your colleague; this way, you will all be working from the same state file.

Further Reading :

Local State Storage:

• Only one person making state file changes
• Simpler file location to remember
• Reasonably secure (workstation access only)
  Cons:
• State files are not easily shared with other admins
• Workstations are more prone to being compromised due to hardware issues or loss of personnel
• Others may have elevated access to a workstation that may not be Azure admins. (Domain admins, desktop support personnel, etc.)
• Workstations are not commonly backed up

Remote State Storage

• One source/repository for state files. (Ensures the team is using the same source files for operations)
• Greater security options (encryption, (IAM) role access, restricted network access)
• More options for backups/redundancy
• Less susceptible to hardware or personnel loss
• Allows more users access to Terraform files and allows for version control
  Cons:
• Adds complexity to configurations and file access (creation of service principal or managed for access)
• Version control becomes more important/problematic
• Access to remote state files is subject to service outages.

When working in a production environment, using Azure remote blob storage for Terraform is recommended. A major benefit is that the blob is automatically encrypted.

State File Security

• Once remote state file storage is in place, you have several options to protect your state file data:
• Encryption at rest – All Azure blob storage is AES256 encrypted.
• Snapshots of state file data – Routine snapshotting of the state file protects against accidental file deletion.
• Apply a Delete Lock to the storage account – Only accounts with “Owner” role access will be able to remove the lock and delete
• the state file blob. If you ensure that you never perform Terraform activity with an “Owner” account, you’ll prevent accidental
• deletion.
• Role Access (IAM) restrictions – If a Service Principle or Managed Service Identity is being used for Terraform activity, you can
• restrict storage account access to only those accounts. As mentioned above, make sure not to set those accounts with “Owner”
• access.
• Selected Network Access to the Storage Account – If using Terraform from a specific VM or VMs, you can restrict access to only
• those VNETs and Subnets that contain those VMs. Additionally, you can “whitelist” specific IP addresses both inside and outside
• your on-premise networks.