Azure DevOps Notes

│ Error: Error ensuring Resource Providers are registered.
│ 
│ Terraform automatically attempts to register the Resource Providers it supports to
│ ensure it's able to provision resources.
│ 
│ If you don't have permission to register Resource Providers you may wish to use the
│ "skip_provider_registration" flag in the Provider block to disable this functionality.
│ 
│ Please note that if you opt out of Resource Provider Registration and Terraform tries
│ to provision a resource from a Resource Provider which is unregistered, then the errors
│ may appear misleading - for example:
│ 
│ > API version 2019-XX-XX was not found for Microsoft.Foo
│ 
│ Could indicate either that the Resource Provider "Microsoft.Foo" requires registration,
│ but this could also indicate that this Azure Region doesn't support this API version.
│ 
│ More information on the "skip_provider_registration" flag can be found here:
│ https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs#skip_provider_registration
│ 
│ Original Error: populating Resource Provider cache: listing Resource Providers: loading results: unexpected status 401 with error: InvalidAuthenticationTokenTenant: The access token is from the wrong issuer 'https://sts.windows.net/30b63709-a926-4eae-82ce-9d4b43daf1e1/'. It must match the tenant 'https://sts.windows.net/735a4c85-c633-4c97-a52c-930ef602b46e/' associated with this subscription. Please use the authority (URL) 'https://login.windows.net/735a4c85-c633-4c97-a52c-930ef602b46e' to get the token. Note, if the subscription is transferred to another tenant there is no impact to the services, but information about new tenant could take time to propagate (up to an hour). If you just transferred your subscription and see this error message, please try back later.
│ 
│   with provider["registry.terraform.io/hashicorp/azurerm"],
│   on provider.tf line 10, in provider "azurerm":
│   10: provider "azurerm" {

This happened because was using an app registration which only had Reader permission on target subscription. Since registering all resource providers “just in case” does go against principle of least privilege, probably better to turn this off and only register providers as needed when they are needed.

To register resource providers, Contributor, Owner, or a Custom Role with permission to do the /register/action operation is needed. Resource Providers are always at subscription level and once registered, can’t unregister when resource types from that Resource Provider still exist in the subscription.

│ Error: checking for presence of existing Network Security Group: (Name "nsg1" / Resource Group "cm-t-azdevops-tfpl-1"): network.SecurityGroupsClient#Get: Failure responding to request: StatusCode=401 -- Original Error: autorest/azure: Service returned an error. Status=401 Code="InvalidAuthenticationTokenTenant" Message="The access token is from the wrong issuer 'https://sts.windows.net/30b63709-a926-4eae-82ce-9d4b43daf1e1/'. It must match the tenant 'https://sts.windows.net/735a4c85-c633-4c97-a52c-930ef602b46e/' associated with this subscription. Please use the authority (URL) 'https://login.windows.net/735a4c85-c633-4c97-a52c-930ef602b46e' to get the token. Note, if the subscription is transferred to another tenant there is no impact to the services, but information about new tenant could take time to propagate (up to an hour). If you just transferred your subscription and see this error message, please try back later."

…still had the service connection pointing to the team's test subscription instead of my own, while provider.tf already referenced my own subscription.

Created new app registration with client secret:

Reader role is enough to verify/create the ADO service connection, but assigned Contributor on subscription level later on to perform terraform deployments. Better would be to assign that at resource group level on an existing resource group, but this way we can deploy and delete the whole resource group after testing.

Deleted old service connection and created new ARM > Service Principal (manual) connection.

Had to modify terraform backend config to point to new service connectino (use service connection name, not subscription name despite the variable names):

• backendServiceArm
• environmentServiceNameAzureRM

Kept getting the following error even though resource group name was defined in .tfvars file and the resource group, along with some other resources, was created successfully:

│ Error: creating/updating Network Security Group: (Name "nsg1" / Resource Group "t-ado-tfpl-1"): network.SecurityGroupsClient#CreateOrUpdate: Failure sending request: StatusCode=404 -- Original Error: Code="ResourceGroupNotFound" Message="Resource group 't-ado-tfpl-1' could not be found."

The problem was that resource_group_name in resources.tf was set like this:

resource "azurerm_public_ip" "T-f903199c-cac7-4637-b877-5b2f62c2ca0d" {
  idle_timeout_in_minutes = 4
  ip_version              = "IPv4"
  name                    = "pip1"
  resource_group_name     = var.rg-name
  sku                     = "Standard"
  sku_tier                = "Regional"
  allocation_method       = "Static"
  location                = var.region
}

This means terraform first creates a resource group with a name as defined in var.rg-name and also tries to create resource which are, from terraform's perspective, independent from the resource group because resource_group_name is simply a string and there is no depends_on attribute.

To fix this, changed it to:

resource "azurerm_network_security_group" "T-8c60003c-c728-4efb-a97a-2da121a46940" {
  name                = "nsg1"
  resource_group_name = var.rg-name.name
  location            = var.region
}