Configuration d'un backend Azure Storage Account pour Terraform

Comment mettre en œuvre et configurer finement un stockage distant sur Azure pour gérer vos états d'Infrastructure as Code Terraform.

Terraform backend

La fonction principale d'un backend est de stocker l'état créé par les exécutions de Terraform après le provisionnement de nos ressources. Cela permet à Terraform d'avoir un endroit unique pour rechercher quelles sont les attentes de nos ressources depuis la dernière exécution de vos scripts ; cela fait également partie de la façon dont Terraform effectue la réconciliation des ressources.
Il existe deux types de backends :

  1. Local: le fichier d'état est stocké sur le système de fichiers local.

  2. Remote : le fichier d'état est stocké dans un système de fichiers ou une base de données distante.

Sur cet article ; nous allons se concentrer sur le remote backend car c'est le mode qui permet de centraliser un fichier d'état Terraform sur notre plateforme Azure.

Exemple de configuration pour un Azure Storage Account :

Lors de l'authentification à l'aide d'Azure CLI ou d'un principal de service (avec un certificat client ou un secret client) vous devez configurer votre backend tel que :

terraform {
  backend "azurerm" {
    resource_group_name  = "StorageAccount-ResourceGroup"
    storage_account_name = "abcd1234"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

Cette configuration pourra aussi être variabilisée pour faciliter les déploiements automatisés via une chaine CI/CD ; ce point sera l'objet d'un futur article 😊

Pour plus de détails, n'hésitez pas à vous rendre sur la documentation officielle d'HashiCorp disponible en suivant ce lien: https://developer.hashicorp.com/terraform/language/settings/backends/azurerm

Configuration du Azure Storage Account

Sur l'Azure Storage Account nous allons pouvoir activer plusieurs fonctionnalités qui vont nous permettre de maximiser leurs usages :

  1. Redundancy : Les données de votre compte de stockage Azure sont toujours répliquées pour garantir la durabilité et la haute disponibilité.
    Par défaut, il est positionné sur GRS pour avoir une redondance sur une seconde région ce qui est dans notre cas d'usage un bon choix :

  1. Allow cross-tenant replication: Désactiver la réplication entre locataires pour limiter la réplication d'objets au sein du même locataire Azure AD.

  2. Disable public access and use private access: Désactiver l'accès publique et ajouter un private endpoint sur un réseau privé, l'idée ici est de limiter l'accès à vos agents DevOps. (VMs / AKS / ... )

Pour expliquer ce point, voici un petit schéma en utilisant une machine virtuelle comme agent Azure DevOps:

En complément, sur ce sujet, n'hésitez pas à regarder mon précédent article détaillant l'usage de private endpoints: Azure Private Link (hashnode.dev)

  1. Recovery: activer les possibilités de point-in-time restore (PITR) et de soft delete pour les containers et blobs :

  2. Tracking: pour permettre l'audit et le versionning nécessaire au PITR:

  3. Encryption: Activer le chiffrement d’infrastructure pour le chiffrement double des données :

Et en script?

Voici maintenat un script, pour vous aider dans l'automatisation de cette étape importante :

## Get all the locations for your Azure Subscription: Get-AzLocation | select Location 
$location = "westeurope"  
$rgName = "azure-love-terraform-2023"  
$accountName = "azstorageacc2023"

$sa = New-AzStorageAccount -ResourceGroupName $rgName -Name $accountName `
    -Location $location -SkuName Standard_GRS -AccessTier Hot `
    -Kind StorageV2 -AllowCrossTenantReplication $false `
    -AllowBlobPublicAccess $false -PublicNetworkAccess Disabled `
    -RequireInfrastructureEncryption -MinimumTlsVersion TLS1_2

# Enable containers soft delete with a retention of 60 days.
Enable-AzStorageContainerDeleteRetentionPolicy -ResourceGroupName $rgName `
    -StorageAccountName $accountName `
    -RetentionDays 60

# Enable blob soft delete with a retention of 60 days.
Enable-AzStorageBlobDeleteRetentionPolicy -ResourceGroupName $rgName `
    -StorageAccountName $accountName `
    -RetentionDays 60

# Enable change feed and versioning.
Update-AzStorageBlobServiceProperty -ResourceGroupName $rgName `
    -StorageAccountName $accountName `
    -EnableChangeFeed $true `
    -ChangeFeedRetentionInDays 60 `
    -IsVersioningEnabled $true

# Enable point-in-time restore with a retention period of 59 days.
# The retention period for point-in-time restore must be at least
# one day less than that set for soft delete.
Enable-AzStorageBlobRestorePolicy -ResourceGroupName $rgName `
    -StorageAccountName $accountName `
    -RestoreDays 59

# View the service settings.
Get-AzStorageBlobServiceProperty -ResourceGroupName $rgName `
    -StorageAccountName $accountName

Il restera à rajouter le private endpoint pour que la solution soit compléte

Ajouter le RBAC nécessaire à votre SPN

Pour permettre l'accès à votre ressource Azure Storage Account, il existe plusieurs possibilités : Clés, SAS ou RBAC.
Je vous conseille l'usage d'un SPN ayant des droits RBAC sur la ressource pour deux principales raisons :

  • simple à mettre en oeuvre

  • identifiable en cas d'audit sur les droits et permssions.

Pour ce faire Microsoft nous fournit en plus des rôles intégrés permettant de positionner facilement des droit avec le principe du moindre privilège :

Rôle AzureDescription
OwnerPeut gérer toutes les ressources de stockage et accéder aux ressources.
ContributorPeut gérer toutes les ressources de stockage, mais ne peut pas gérer l’accès aux ressources.
ReaderPeut voir des informations sur le compte de stockage, mais ne peut pas voir les clés de compte.
Storage Account ContributorPeut gérer le compte de stockage, obtenir des informations sur les ressources et les groupes de ressources de l’abonnement, et créer et gérer les déploiements des groupes de ressources de l’abonnement.
User Access AdministratorPeut gérer l’accès au compte de stockage.
Storage Blob Data ContributorLire, écrire et supprimer des conteneurs et objets blob du stockage Azure.
Storage Blob Data OwnerFournit un accès total aux conteneurs d’objets blob et aux données du Stockage Azure, notamment l’attribution du contrôle d’accès POSIX.
Storage Blob Data ReaderLire et répertorier des conteneurs et objets blob du stockage Azure.

Dans notre cas, nous privilégerons donc le rôle RBAC "Storage Blob Data Contributor"

Did you find this article valuable?

Support Antoine LOIZEAU by becoming a sponsor. Any amount is appreciated!