
GitHub Automation with Terraform Pt 1
Making a GitHub repo module in the style of AVM
Making a GitHub repo module in the style of AVM
Using the moved() block to avoid recreation
A name for thy role definitions
Use RBAC for your Azure Terraform Backend Are you using Azure RBAC to access your Azure Terraform state? Are you sure 😉? Have you tried turning off access keys & does everything still work? Hopefully it’s obvious why storage account access keys should be avoided, but just in case - they are long-lived tokens that provide full access to your storage account, without requiring the need to authenticate to your Azure tenancy. SAS tokens are constrained, so a bit better, but Entra ID is the way.
Regardless of whether you are writing AVM modules, or simply using them, it is useful to understand the “shared interfaces”, as described on the AVM website. Each module must implement the following interfaces if they are supported by the underlying resource: What does this mean as a module consumer? It means there should be a module input available for each of these: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 module "keyvault" { source = "Azure/avm-res-keyvault-vault/azurerm" version = "0.5.1" name = module.naming.key_vault.name_unique location = azurerm_resource_group.this.location resource_group_name = azurerm_resource_group.this.name tenant_id = data.azurerm_client_config.this.tenant_id sku_name = "standard" role_assignments = { # define the role assignments } lock = { # define the resource locks } private_endpoints = { # define the private endpoints } diagnostic_settings = { # define the diagnostic settings } // etc tags = var.tags } Whether you use them, is optional. Lets dive into some examples!