Create infrastructure on Azure CLI with Terraform

Setting up a shared remote state for multiple users

For this article we will be looking at the Azure CLI that has Terraform baked into the CLI. There is no need to install Terraform, it is already there for you to use.

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 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

terraform init

Next type

terraform plan

this will check your code to make sure its accurate.

Now type

terraform apply

Check your Azure Blob storage to ensure that the terraform state file has uploaded. You can now share this main.tf file with your colleagues and 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 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 are subject to service outages

When working in a production environment it is recommended to use an Azure remote blob storage for Terraform. A major benefit is that the blob automatically encrypted.

State File Security

  • Once remote state file storage is in place, you have a number of options to protect your state file data:
  • Encrypt ion at rest – All Azure blob storage is AES256 encrypted.
  • Snapshot s of st at e file dat a – Routine snapshotting of the state file protects against accidental file deletion.
  • Apply a Delet e Lock t o t he st orage 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) restrict ions – 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.
  • Select ed Net work Access t o t he St orage 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.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

Follow by Email
YouTube
YouTube
Instagram