TerraForm – Using the new Azure AD Provider
Tags: codeproject, technology, azuread, serviceprincipal
Published: 2020-06-22 18:19:29

---
title: TerraForm – Using the new Azure AD Provider
published: true
date: 2020-06-04 09:00:00 UTC
tags: CodeProject,Technology,azuread,serviceprincipal
canonical_url: 
---

So by using TerraForm, you gain a lot of benefits, including being able to manage all parts of your infrastructure using HCL languages to make it rather easy to manage.

A key part of that is not only being able to manage the resources you create, but also access to them, by creating and assigning storage principals. In older versions of TerraForm this was possible using the azurerm\_azuread\_application and other elements. I had previously done this in the Kubernetes template I have on [github](https://github.com/KevinDMack/TerraformKubernetes).

Now, with TerraForm v2.0, there have been some pretty big changes, including removing all of the Azure AD elements and moving them to their own [provider](https://www.terraform.io/docs/providers/azuread/index.html), and the question becomes “How does that change my template?”

Below is an example, it shows the creation of a service principal, with a random password, and creating an access policy for a keyvault.

```
resource "random\_string" "kub-rs-pd-kv" { length = 32 special = true}data "azurerm\_subscription" "current" { subscription\_id = "${var.subscription\_id}"}resource "azurerm\_azuread\_application" "kub-ad-app-kv1" { name = "${format("%s%s%s-KUB1", upper(var.environment\_code), upper(var.deployment\_code), upper(var.location\_code))}" available\_to\_other\_tenants = false oauth2\_allow\_implicit\_flow = true}resource "azurerm\_azuread\_service\_principal" "kub-ad-sp-kv1" { application\_id = "${azurerm\_azuread\_application.kub-ad-app-kv1.application\_id}"}resource "azurerm\_azuread\_service\_principal\_password" "kub-ad-spp-kv" { service\_principal\_id = "${azurerm\_azuread\_service\_principal.kub-ad-sp-kv1.id}" value = "${element(random\_string.kub-rs-pd-kv.\*.result, count.index)}" end\_date = "2020-01-01T01:02:03Z"}resource "azurerm\_key\_vault" "kub-kv" { name = "${var.environment\_code}${var.deployment\_code}${var.location\_code}lkub-kv1" location = "${var.azure\_location}" resource\_group\_name = "${azurerm\_resource\_group.management.name}" sku { name = "standard" } tenant\_id = "${var.keyvault\_tenantid}" access\_policy { tenant\_id = "${var.keyvault\_tenantid}" object\_id = "${azurerm\_azuread\_service\_principal.kub-ad-sp-kv1.id}" key\_permissions = ["get",] secret\_permissions = ["get",] } access\_policy { tenant\_id = "${var.keyvault\_tenantid}" object\_id = "${azurerm\_azuread\_service\_principal.kub-ad-sp-kv1.id}" key\_permissions = ["create",] secret\_permissions = ["set",] } depends\_on = ["azurerm\_role\_assignment.kub-ad-sp-ra-kv1"]}
```

Now as I mentioned, with the change to the new provider, you will see a new version of this code be implemented. Below is an updated form of code that generates a service principal with a random password.

```
provider "azuread" { version = "=0.7.0"}resource "random\_string" "cds-rs-pd-kv" { length = 32 special = true}resource "azuread\_application" "cds-ad-app-kv1" { name = format("%s-%s%s-cds1",var.project\_name,var.deployment\_code,var.environment\_code) oauth2\_allow\_implicit\_flow = true}resource "azuread\_service\_principal" "cds-ad-sp-kv1" { application\_id = azuread\_application.cds-ad-app-kv1.application\_id}resource "azuread\_service\_principal\_password" "cds-ad-spp-kv" { service\_principal\_id = azuread\_service\_principal.cds-ad-sp-kv1.id value = random\_string.cds-rs-pd-kv.result end\_date = "2020-01-01T01:02:03Z"}
```

Notice how much cleaner the code is, first we aren’t doing the ${} to do string interpolation, and ultimately the resources are much cleaner. So the next question is how do I connect this with my code to assign this service principal to a keyvault access policy.

You can accomplish that with the following code, which is in a different file in the same directory:

```
resource "azurerm\_resource\_group" "cds-configuration-rg" { name = format("%s-Configuration",var.group\_name) location = var.location }data "azurerm\_client\_config" "current" {}resource "azurerm\_key\_vault" "cds-kv" { name = format("%s-%s%s-kv",var.project\_name,var.deployment\_code,var.environment\_code) location = var.location resource\_group\_name = azurerm\_resource\_group.cds-configuration-rg.name enabled\_for\_disk\_encryption = true tenant\_id = data.azurerm\_client\_config.current.tenant\_id soft\_delete\_enabled = true purge\_protection\_enabled = false sku\_name = "standard" access\_policy { tenant\_id = data.azurerm\_client\_config.current.tenant\_id object\_id = data.azurerm\_client\_config.current.object\_id key\_permissions = ["create", "get",] secret\_permissions = ["set", "get", "delete",] } access\_policy { tenant\_id = data.azurerm\_client\_config.current.tenant\_id object\_id = azuread\_service\_principal.cds-ad-sp-kv1.id key\_permissions = ["get",] secret\_permissions = ["get",] }}
```

Notice that I am able to reference the “azuread\_service\_principal.cds-ad-sp-kv1.id” to access the newly created service principal without issue.