Overcoming Terraform Deployment Challenges: How to fix authorization issues using Service Principal on Azure Cloud
Tags: devops, terraform, azure, error403
Published: 2023-08-26 09:10:38

In my opinion, Terraform is one of the most powerful tools for automating resource deployment. However, even with the right permissions and configurations, there will always be challenges that you will have to overcome. The author describes her triumphant experience provisioning Azure resources with Terraform, overcoming perplexing errors and roadblocks.

#### Before I go into details about the issues I faced and what worked, here is a short overview of Terraform's use for provisioning Azure VMs
 (you can view this detailed, low-level example at https://learn.microsoft.com/en-us/azure/virtual-machines/windows/quick-create-terraform):

- 
Install Terraform on your local PC by downloading the binary from the official Terraform website.

- 
Create an Azure account if you haven't already done so, and then create a service principal with contributor access. You can use this service principal to authenticate Terraform with Azure.

- 
Create a directory for your Terraform files and initialize it with the Azure provider. You can do this by running terraform init in the directory and specifying the Azure provider.

- 
Create a Terraform configuration file (usually named main.tf) that defines the resources you want to provision. For example, you can define an Azure VM and an Azure Blob Storage resource.

- 
Run terraform plan to preview the changes that Terraform will make to your Azure resources. This step is optional but highly recommended as it can help you catch any potential issues before making any changes.

- 
Run terraform apply to apply the changes to your Azure resources. Terraform will prompt you to confirm the changes before proceeding.

- 
Finally, manage your Azure resources going forward, you can use Terraform to update, delete or add new resources.

### Back to the main challenge!

![Configured Service Principal](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/72yfst1fy7vu6m2eog0i.png)

My sole purpose was to provision Azure resources using Terraform. Despite having a well-configured service principal with the appropriate permissions, Hmm! My expectations of it going so smoothly came short. Attempts to log in with both the service principal and Az Login methods only compounded the problem, yielding errors that seemed to have a false positive (so to speak). In an attempt to resolve this issue, I engaged Microsoft's support, tweaking permissions and meticulously reviewing configurations, but to no avail.


![Terraform Bug 1](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j97qs997iq9r9qpbbc7j.png)


![Terraform Bug 2](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zno8zpuneqr65ehtge32.png)


![Terraform Bug](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9ds2vn1zt2fr2bd1wpoh.png)

The breakthrough came unexpectedly when, out of sheer determination, I decided to switch to the root Azure account and opted for Az Login. And just like that, Terraform began to cooperate. 


![Terraform solution 80%](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tvvsjwqw9pd9i69gfo62.png)


![Terraform fix](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zqo7wliw93cqjngw6gqb.png)

This unconventional approach revealed the complexity of interactions between Terraform, Azure, and authentication methods, which provided the solution. In addition to emphasizing the importance of adaptability and creativity in problem-solving, this experience also emphasizes that it is sometimes possible to reach the desired destination by taking an alternative path.


Well, this is obviously not the best approach and practice I'd adopt going forward, but documenting this here may help someone tomorrow. I believe success often comes when we approach obstacles with an open mind and a willingness to explore unconventional solutions.