Azure Verified Modules Part2 - Shared interfaces
Azure verified modules part 2 - Shared interfaces
AVM modules have shared interfaces. It is necessary to understand these interfaces regardless if you use or write AVM modules. Resource modules support below optional features/extension resources, as specified, if it is supported by the primary resource. The top-level variable/parameter are also named the same. So we have the same names in every module. AVM interfaces acts as a shim over the existing API, ensuring consistent naming conventions. This consistency extends from the AVM modules to the underlying API, facilitating seamless integration and usage. This is a great benefit. AVM is worrying about providing the right data passed in the underlying api.
Interfaces
There are several interface
- Diagnostic Settings
- Role Assignments
- Resource Locks
- Tags
- Managed Identities
- Private Endpoints
- Customer Managed Keys
- Azure Monitor Alerts
What does this mean as a module consumer? It means there should be a module input available for each of these:
1module "storage_account" {
2 source = "Azure/avm-res-storage-storageaccount/azurerm"
3 version = "~> 0.1"
4 account_replication_type = "LRS"
5 location = azurerm_resource_group.this.location
6 name = local.storage_account_name
7 resource_group_name = azurerm_resource_group.this.name
8 infrastructure_encryption_enabled = true
9 containers = {
10 demo = {
11 name = "demo"
12 container_access_type = "private"
13 }
14 }
15 managed_identities = { # managed identities
16 }
17 customer_managed_key = { #customer managed key
18
19 }
20 private_endpoints = { # private endpoints
21 }
22 role_assignments = { # role assignments
23 }
24 tags = { # tags
25 }
26}
Shared interfaces are optional. You don't have to use them.
Role Assigments
Normally we have to to do role assignments outside the module for example:
1resource "azurerm_role_assignment" "role_assignment" {
2 scope = data.azurerm_storage_account.storage_account.id
3 role_definition_name = "Storage Blob Data Reader"
4 principal_id = data.azurerm_client_config.current.object_id
This works but in AVM we can do the role assignment directly in the module
1module "storage_account" {
2 source = "Azure/avm-res-storage-storageaccount/azurerm"
3 version = "~> 0.1"
4 account_replication_type = "LRS"
5 location = azurerm_resource_group.this.location
6 name = local.storage_account_name
7 resource_group_name = azurerm_resource_group.this.name
8 infrastructure_encryption_enabled = true
9 containers = {
10 demo = {
11 name = "demo"
12 container_access_type = "private"
13 }
14 }
15 managed_identities = { # managed identities
16 }
17 customer_managed_key = { #customer managed key
18 }
19
20 private_endpoints = { # private endpoints
21 }
22 role_assignments = { # role assignments
23 role_assignment_1 = {
24 role_definition_id_or_name = "Storage Blob Data Reader"
25 principal_id = data.azurerm_client_config.current.object_id
26 skip_service_principal_aad_check = false
27 },
28 }
29 tags = { # tags
30 }
31}
The role_assignment_1 name is arbitrary. You can choose a different name. This can also data_reader for example.
Private Endpoints
Private endpoint are working in the same way
1module "storage_account" {
2 source = "Azure/avm-res-storage-storageaccount/azurerm"
3 version = "~> 0.1"
4 account_replication_type = "LRS"
5 location = azurerm_resource_group.this.location
6 name = local.storage_account_name
7 resource_group_name = azurerm_resource_group.this.name
8 infrastructure_encryption_enabled = true
9 containers = {
10 demo = {
11 name = "demo"
12 container_access_type = "private"
13 }
14 }
15 managed_identities = { # managed identities
16 }
17 customer_managed_key = { #customer managed key
18 }
19
20 private_endpoints = {
21 primary = {
22 private_dns_zone_resource_ids = [azurerm_private_dns_zone.storage_account.id]
23 subnet_resource_id = module.virtual_network.subnets["private_endpoints"].id
24 subresource_name = ["blob"]
25 }
26
27 role_assignments = { # role assignments
28 role_assignment_1 = {
29 role_definition_id_or_name = "Storage Blob Data Reader"
30 principal_id = data.azurerm_client_config.current.object_id
31 skip_service_principal_aad_check = false
32 },
33 }
34tags = {
35 env = "Dev"
36 owner = "Seth "
37 dept = "IT"
38 }
39}
I showed two examples. The same way of working can be used for other resource. For instance a key vault or a virtual machine. So once you learned to use the interface in one module you can use use them in other Azure Verified Modules.
Resources
RMFR4 - Category: Composition - AVM Consistent Feature & Extension Resources Value Add
interfaces
Introduction to using Azure Verified Modules for Terraform