I'm implementing a Terraform template, that deploys an Azure VM, based on a custom image that resides on another tenant. I've provided permissions to an AppRegistration, and validated that using Az CLI I can deploy a VMSS referring to that same shared image.
However, if I use Terraform to deploy the VM, I get this error:
Error: compute.VirtualMachinesClient#CreateOrUpdate: Failure sending request: StatusCode=403 -- Original Error: Code="LinkedAuthorizationFailed" Message="The client has permission to perform action 'Microsoft.Compute/galleries/images/versions/read' on scope '/subscriptions//resourceGroups/RG-Images/providers/Microsoft.Compute/virtualMachines/VM1', however the current tenant '' is not authorized to access linked subscription '***'."
Terraform is using the AppRegistration that was created. however, it fails with that error
I've followed this how-to, successfully, that usees Az cli.
https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/share-images-across-tenants
I understand by the error message, that the user has the permissions, but the issue is between the 2 tenants, is that it? What else can I do to fix this?
Initially please check with the RBAC permissions on the two tenants like Virtual machine contributor or Network Contributor role .
This issue with cross tenant may be even fixed in terraform azurerm
provider version 1.34.0 or later
provider "azurerm" {
version = "~> 1.34.0"
}
And you can make use of auxiliary_tenant_ids = ["<tenant2 Id>"] to mention both the tenants while using shared image gallery .See shared image gallery /terraform/github.com by #rajaie-algorithmia
provider "azurerm" {
subscription_id = "${var.subscription_id}"
client_id = "${var.client_id}"
client_secret = "${var.client_secret}"
tenant_id = "${var.tenant_id}"
auxiliary_tenant_ids = ["${var.sig_tenant_id}"] #give the other tenant Id here
}
References:
share-images-across-tenants | microsoft docs
azure portal : how-to-share-gallery-vm-images-across-azure-tenants |Ajay varma| axiom
Related
I am trying to create a Client_secret for My service principal using the below code :
data "azuread_service_principal" "existing_SP" {
display_name = "TestAppRegistration"
}
resource "azuread_service_principal_password" "Client_Secret" {
service_principal_id = data.azuread_service_principal.existing_SP.object_id
}
Doing a terraform-apply it get successfully created but I don't see it in the Secrets and certificates section of the app registration:
But when I check the tfstate , it shows the value there created for the service principal but the object Id is same as the enterprise application present for the same app registration:
So, My question:
How can I create a client secret using terraform, is there something I am doing wrong ?
If I am doing correct then where is the secret generated can be found in portal?
How can I create a client secret using terraform, is there something I
am doing wrong ?
Yes , You are doing everything correctly.
But to clear the confusion here , as you may already know there are 2 types of azure ad application i.e. app registrations and enterprise application. In terraform or powershell or cli the App Registration is know as Azure AD application and the Enterprise Application for the same app registration is know as Service Principal. So , if you have created from Portal by going to app registration blade , then bydefault a service principal is created for it , but its not the same if you create a app registration from Powershell or Terraform.
And By default you will be not be able to see the secret or certificate created for service principal from portal but you will be defintely able to use it with the client-id for authentication purpose .
For example :
I tested this on my environment using your code and I took the value of password present in tfstate file and used it to do az login:
Note: Its safe to use terraform for creating a service principal password as it will be stored in the tfstate file so, you won't face difficulty in searching for it .
If I am doing correct then where is the secret generated can be found
in portal?
But if you are trying to look for the secret from portal , then I will suggest you to use azuread_application:
data "azuread_application" "example" {
display_name = "postman"
}
resource "azuread_application_password" "example" {
display_name = "terraformgenerated"
application_object_id = data.azuread_application.example.object_id
}
I'm an owner of an Azure resource group but not have permissions on the subscription or on the management group.
When configuring the "azurerm" provider inside my .tf file, I've added subscription id and tenant id (I'm not the owner of that subscription).
--------------------- UPDATE ---------------------
I'm trying to apply Linux virtual machine using Terraform but having authorization issues while planning the .tf file.
I've listed all my accounts using Azure CLI (want to connect the second subscription in the output below):
I've succeeded authenticating to the subscription using Azure CLI with the command (it worked):
az account set --subscription="SUBSCRIPTION_ID"
It's my default and current subscription:
Also, I was able to create and manage resources inside my resource group in that subscription using Azure CLI.
However, I added the exact tenant ID and the exact subscription ID inside my .tf file and still got the same credentials errors during the "terraform plan".
Using Azure CLI or Azure portal I am able to create and manage resources inside the resource group's scope, although using terraform I'm facing problems.
Thank you :)
According to your story, you just set the tenant id and subscription id in the azure provider, so it seems you authenticate via Azure CLI. No matter you have a user account or a service principal, the owner role of the resource group is enough to create virtual machine in the resource group. In this way, you need to logging into the Azure CLI first. As it shows in the link I have provided.
I have a project that is running on Azure DevOps that requires creating a KeyVault and giving a series of managed AppService identities access to secrets in that vault.
Because of Terraform not being able to give its own service connection access to the key vault(this is a bug of some kind), I am forced to create ResourceGroup and Keyvault with SP access before Terraforming.
When running terraform import on resourcegroup and Keyvault through a PowerShell task:
terraform init
$state = terraform state list
if ($state -like '*azurerm_resource_group.instancerg*' -and '*azurerm_key_vault.instancekeyvault*') {
Write-Host "Resources have already been imported!"
}
else {
terraform import azurerm_resource_group.instancerg /subscriptions/$(subscriptionid)/resourceGroups/rgname
terraform import azurerm_key_vault.instancekeyvault /subscriptions/$(subscriptionid)/resourceGroups/rgname/providers/Microsoft.KeyVault/vaults/keyvaultname
}
Failure happens on terraform import commands:
'Authenticate using a Service Principal' To authenticate to Azure
using a Service Principal, you can use the separate auth method -
instructions for which can be found here:'
My main.tf contains:
provider "azurerm" {
version = "=2.7.0"
subscription_id = var.subscriptionid
client_id = var.devopsserviceconnectionaid
client_secret = var.devopsserviceconnectionpw
tenant_id = var.tennantid
features {}
}
The variables are all linked to the proper credentials.
From what I understand Terraform should pick up on what authentication method that is being used based on the credentials that are in the block above or specific env variables (that are also present...) but somehow Terraform still thinks I'm trying to auth through Azure Cli and not Service principal.
You can use manage identities in keyvault in terraform as shown below.
object_id = azurerm_app_service.app.identity.0.principal_id
Web app is as below creating managed identity
KV as below
The order should be create web app with managed identity, then the KV then the KV access policy.
For authenticate with Azure pipelines service connection below works fine but you need to pass the arguments via the pipeline.
for further information check this blog here
Full PowerShell based implementation calling terraform with Azure DevOps pipelines is explained here. This implementation prevents any azure resources as prerequisite before terraforming. Only prerequisite is creating the SPN to enable authentication and authorization.
I want to deploy some resources on Azure with Terraform.
On Azure, I have an account with "Owner rights" on one Resource Group only(RGName). Not at the subscription level.
From my linux server, I installed "az cli" and I did "az login". At this step, everything is OK.
The problem appears when I want to execute terraform to create one resource.
Content of provider.tf (the only one .tf file for now) :
provider "azurerm" {
}
If I do a "terraform plan", it works.
If I add the following line, it fails. Please see the error at the end :
resource "azurerm_virtual_network" "myterraformnetwork" {
name = "myVnet"
address_space = ["10.0.0.0/16"]
location = "eastus"
resource_group_name = "RGName"
tags = {
environment = "Terraform Demo"
}
}
I do not have right on subscription level but I do not need to.
With the Azure WebUI I can create resource on this Resource Group without problem.
The error :
Error: Error ensuring Resource Providers are registered: Cannot register provider Microsoft.DevSpaces with Azure Resource Manager: resources.ProvidersClient#Register: Failure responding to request: StatusCode=403 -- Original Error: autor
est/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client 'accountName' with object id 'IDaccountName' does not have authorization to perform action 'Microsoft.DevSpaces/r
egister/action' over scope '/subscriptions/subscriptionID' or the scope is invalid. If access was recently granted, please refresh your credentials.".
on provider.tf line 1, in provider "azurerm":
1: provider "azurerm" {
Thank you all !
If anyone else has this issue in a corporate (restricted) Azure environment, and doesn't have the patience to register the provider (which may not be necessary if you don't use the specified terraform resource) - have a look at https://github.com/terraform-providers/terraform-provider-azurerm/issues/4440
Specifically, this may help:
provider "azurerm" {
skip_provider_registration = "true"
It obviously won't help if you actually need the resource that fails to get registered (in our case it was Cannot register provider Microsoft.DevSpaces with Azure Resource Manager, but the resource will be variable depending on your environment and what Terraform decides to support)
For your issue, when you have the Owner role of the resource group, you can create new resources or manage the existing resources as you want. So permission is no problem. With the test on my side, it works well using a user has the Owner role of the resource group.
As the error shows, I think the possible reason is that you have multiple subscriptions in the tenant and the current subscription is not the right one which the user has the right permission. You can try to take a check and set the right subscription via the command:
az account set --subscription subscription_id
Thank you for your answer.
I got this when I execute "az account list" :
"cloudName": "AzureCloud",
"id": "***********0d43",
"isDefault": true,
"name": "BU*******",
"state": "Enabled",
"tenantId": "TENANTID",
"user": {
"name": "LOGINNAME",
"type": "user"
I do not have rights on this subscription but it is the only one that I know.
On Azure WebUI I can see that the RGName is on the same subscription.
This is a capture from Azure WebUI on the RGName :
Azure WebUI
Thank you
You may need to register the Resource provider by clicking on register as shown in below screenshot under subscription id.
I have two subscriptions in Azure. Let's call them sub-dev and sub-prod. Under sub-dev I have resources for development (in a resource group rg-dev) and under sub-prod resources for production (in a resource group rg-prod).
Now, I would like to have only one state-file for both dev and prod. I can do this as I am using Terraform workspaces (dev and prod). There is a Storage Account under sub-dev (rg-dev) named tfsate. It has a container etc. The Azure backend is configured like this:
terraform {
backend "azurerm" {
resource_group_name = "rg-dev"
storage_account_name = "tfstate"
container_name = "tfcontainer"
key = "terraform.tfstate"
}
}
If I want to apply to the dev environment I have to switch Az Cli to the sub-dev. Similarly, for production, I would have to use sub-prod. I switch the default subscription with az cli:
az account set -s sub-prod
Problem is that the state's storage account is under sub-dev and not sub-prod. I will get access errors when trying to terraform init (or apply) when the default subscription is set to sub-prod.
Error: Failed to get existing workspaces: Error retrieving keys for Storage Account "tfstate": storage.AccountsClient#ListKeys: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client 'user#example.com' with object id '<redacted>' does not have authorization to perform action 'Microsoft.Storage/storageAccounts/listKeys/action' over scope '/subscriptions/sub-prod/resourceGroups/rg-dev/providers/Microsoft.Storage/storageAccounts/tfstate' or the scope is invalid. If access was recently granted, please refresh your credentials."
I have tried couple of things:
I added subscription_id = "sub-dev"
I generated a SAS token for the tfstate storage account and added the sas_token config value (removed resource_group_name)
but in vain and getting the same error.
I tried to az logout but terraform requires me to login first. Do I have to tune the permissions in the Azure end somehow (this is hard as the Azure environment is configured by a 3rd party) or does Terraform support this kind of having your state file under different subscription setup at all?
For better or worse (I haven't experimented much with other methods of organising terraform) we use terraform in the exact way you are describing. A state file, in a remote backend, in a different subscription to my resources. Workspaces are created to handle environments for the deployment.
Our state files are specified like this:
terraform {
required_version = ">= 0.12.6"
backend "azurerm" {
subscription_id = "<subscription GUID storage account is in>"
resource_group_name = "terraform-rg"
storage_account_name = "myterraform"
container_name = "tfstate"
key = "root.terraform.tfstate"
}
}
We keep our terraform storage account in a completely different subscription to our deployments but this isn't necessary.
When configuring your state file like so, it authenticates to the remote backend via az CLI, using the context of the person interacting with the CLI. This person needs to have the "Reader & Data Access" role to the storage account in order to dynamically retrieve the storage account keys at runtime.
With the above state file configured, executing Terraform would be
az login
az account set -s "<name of subscription where you want to create resources>"
terraform init
terraform plan
terraform apply
There's another way to do that. You can use the Access Key associated with the Storage Account on the other subscription(the one you want to have the state files on) and export it as an environment variable.
Bash:
export ARM_ACCESS_KEY=$(az storage account keys list --resource-group $RESOURCE_GROUP_NAME --account-name $STORAGE_ACCOUNT_NAME --query '[0].value' -o tsv)
Powershell:
$env:ARM_ACCESS_KEY=$(az storage account keys list --resource-group $RESOURCE_GROUP_NAME --account-name $STORAGE_ACCOUNT_NAME --query '[0].value' -o tsv)
Then switch to the subscription you want to deploy to and deploy.