On the CI/CD, I want to reduce using of secrets key. I think this feature is crucial.

azurerm provider is also supported.
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/service_principal_oidc#oidc-token

Testing the use of azure key vault secrets and running into a few issues. These are the scenarios I am testing:

1. KeyVault not found
2. Secret disabled
3. Secret not found
4. Secret deleted
5. Secret present but not active (activation start > date)
6. Secret expired (date > expiration date)

I have all my kv values in base.tfvars and refrence them in variables.tf

fwCommonUserName = "<%= azure_secret("fwCommonUserName") %>"

variable "fwCommonUserName" {
description = "The common firewall username."
}

It appears that the plugin is putting the message in the value when there is a problem. It would be more helpful to return the value as null so that one can use tf input variable validation to determine if one should go on without the secret.

My results:

1. when doing ts up I get the message "WARN: Vault not found " on stdout and tf tries to replace the resource

module.spokeNetwork["sharedServices"].module.spokeNetworkInstance["web"].azurerm_windows_virtual_machine.vm_spoke_instance must be replaced

-/+ resource "azurerm_windows_virtual_machine" "vm_spoke_instance" {
~ admin_password = (sensitive value)
~ admin_username = "vmadmin" -> "WARN: Vault not found " # forces replacement

2. similar to 1. but the message is "WARN: Operation get is not allowed on a disabled secret." and it tries to replace the resource

module.fwPaloAltoTransitCommon01.azurerm_linux_virtual_machine.vm_firewall must be replaced

-/+ resource "azurerm_linux_virtual_machine" "vm_firewall" {
~ admin_username = "vmadmin" -> "Operation get is not allowed on a disabled secret." # forces replacement

3. similar to 1. and 2. but the message is "WARN: A secret with (name/id) fwCommonUserNames was not found in this key vault. If you recently deleted this secret you may be able to recover it using the correct recovery command. For help resolving this issue, please see https://go.microsoft.com/fwlink/?linkid=2125182" and it tries to replace the resource

module.fwPaloAltoTransitCommon01.azurerm_linux_virtual_machine.vm_firewall must be replaced

-/+ resource "azurerm_linux_virtual_machine" "vm_firewall" {
~ admin_username = "vmadmin" -> "A secret with (name/id) fwCommonUserNames was not found in this key vault. If you recently deleted this secret you may be able to recover it using the correct recovery command. For help resolving this issue, please see https://go.microsoft.com/fwlink/?linkid=2125182" # forces replacement

4. same message as 3. and it tries to replace the resource
   5 and 6. the start and expiration dates are ignored. the resource gets created/modified as usual.

I am trying to solve the same problem that is answered in this post with Terraspace.

My .env file has both ARM_SUBSCRIPTION_ID set for the subscription that is supposed to hold the resources and ARM_BACKEND_SUBSCRIPTION_ID for the subscription where we are storing our terraform state.

My backend config looks like this:

terraform {
  backend "azurerm" {
    resource_group_name  = "<Name>"
    storage_account_name = "<%= expansion('<NAME>:ENV') %>"
    container_name       = "terraform-state"
    key                  = "<%= expansion(':PROJECT/:LOCATION/:APP/:ROLE/:ENV/:BUILD_DIR/terraform.tfstate') %>"
    subscription_id      = "<%= expansion(':ARM_BACKEND_SUBSCRIPTION_ID') %>"
  }
}

Yet the builder tries to find and create the resource group and storage account in the subscription set in ARM_SUBSCRIPTION_ID. I don't know Ruby but from scanning the code in here it seems that the subscription parameter from the backend block is not read anywhere.

I would like to request a feature in form of configuration options to enable Network ACL support for TerraspacePluginAzurerm auto-creation of the backend Storage Account.

Current implementation of the plugin creates the storage account backend with no Network ACLs, so the container can be accessed from anywhere.

The configuration could be:

• Specify the default action to the Network Access ("Allow" or "Deny") for the storage account
• Specify one or more network rules if the default action is "Deny":
• The rules would contain CIDR and Action parameters

Security would be greatly improved if network access policies could be specified for the backend configuration.
Also, if security policies require an ACL to be present, the auto-creation of the storage account would fail.

Summary

Add support for soft-delete for containers and blobs in Azure for the backend storage account.

Motivation

When the creation of the storage account for the backend is managed by Terraspace, soft-delete for containers and blobs is not enabled by default. It would be useful to have this enabled by default to restore a previous state file in case something went horribly wrong. Without this feature we have to enable these storage account settings manually and this might be forgotten.

Guide-level explanation

Reference-level explanation

Drawbacks

Unresolved Questions

Would be nice to support also Azure MSI authentication.

Terraform solution ( ARM_USE_MSI=true environment variable for fallbacking to MSI authentication ):
https://registry.terraform.io/providers/hashicorp/azuread/latest/docs/guides/managed_service_identity#configuring-managed-service-identity-in-terraform

Related:
https://github.com/Azure/azure-sdk-for-ruby/blob/master/runtime/ms_rest_azure/lib/ms_rest_azure/credentials/msi_token_provider.rb

Thanks

EDIT:
CLI authentication is also useful imho ( az login && terraspace .. )
https://github.com/Azure/azure-sdk-for-ruby/blob/master/runtime/ms_rest_azure/lib/ms_rest_azure/credentials/azure_cli_token_provider.rb