Key Vault Access Policy doesnt work

[ghost]

This issue was originally opened by @jamie3 as hashicorp/terraform#20177. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Terraform Version

Terraform v0.11.10

Terraform Configuration Files

terraform {
  required_version = ">= 0.11.8"

  backend "azurerm" {
    access_key           = "..."
    storage_account_name = "..."
    container_name       = "tfstate"
    key                  = "infrastructure.tfstate"
  }
}

provider "azurerm" {
  subscription_id = "${var.subscription_id}"
}

locals {

  env = "${terraform.workspace}"  

  azure_ad_tenant_id = "TENANT_ID"

  resource_group_name = "myrg"
}

resource "azurerm_key_vault" "vault" {
  name                        = "keyvault"
  location                    = "${var.location_r1}"
  resource_group_name         = "${local.resource_group_name}"
  enabled_for_disk_encryption = true
  tenant_id                   = "${local.azure_ad_tenant_id}"

  sku {
    name = "standard"
  }

  // SpringBootSP
  access_policy {
    tenant_id = "${local.azure_ad_tenant_id}"
    object_id = "OBJECT_ID_1"
    application_id = "APP_ID_1"

    secret_permissions = [
      "get",
      "list"
    ]
  }

  network_acls {
    default_action = "Deny"
    bypass         = "AzureServices"
  }
}

Expected Behavior

Spring Boot app should have access to the secret

Actual Behavior

com.microsoft.azure.keyvault.models.KeyVaultErrorException: Status code 403, {"error":{"code":"Forbidden","message":"Access denied","innererror":{"code":"AccessDenied"}}}

One thing to mention is that when I run the command, the keyvault and spring boot app works
az keyvault set-policy --name <your_keyvault_name>
--secret-permission get list
--spn <your_sp_id_create_in_step1>

I noticed in the portal that the SP in Access Policies is listed differently when running TF vs CLI

TF Shows:
(Monitor Icon) DigitalApiTeamSP
(Directory ID: TENANT_ID, Directory Name: undefined) + APPLICATION

CLI Shows:
(Person Icon) DigitalApiTeamSP
APPLICATION (Directory ID: TENANT_ID, Directory Name: undefined)

Steps to Reproduce

terraform init
terraform plan
terraform apply

Additional Context

n/a

References

https://github.com/Microsoft/azure-spring-boot/tree/master/azure-spring-boot-samples/azure-keyvault-secrets-spring-boot-sample

[odee30]

I have also experienced this exact issue only with trying to write a secret to the vault. Found that if the access policies with matching permissions over keys and secrets were manually added via the UI, the terraform configuration was able to write the secret to the vault. Remove the manual permissions, replace with those created via the azurerm_key_vault_access_policy resource and get back AccessDenied.

[5RK7N]

Default action is set to deny when no network rules matched. A virtual_network_subnet_ids or ip_rules can be added to network_acls block to allow request that is not Azure Services (https://www.terraform.io/docs/providers/azurerm/r/key_vault.html)

Define subnet-id where the spring-boot application is running:

network_acls {
    default_action             = "Deny"
    bypass                     = "AzureServices"
    virtual_network_subnet_ids = "${azurerm_subnet.springboot.id}"
}

Or just allow all action:

network_acls {
    default_action = "Allow"
    bypass         = "None"
}

[AntonChernysh]

+1 with this problem

[AntonChernysh]

Ok, way to fix this:

• DO NOT use Object ID from Application Registration, in this case you will get an objectID of an application not the SP. Instead get your application objeectId.
  I used this command to get all SPs in my organization and then found correct objectId by SP name : az ad app list --all --query "sort_by([].{Name:displayName, ObjID:objectId}, &Name)" --out table .

• DO NOT use azurerm_key_vault_access_policy resource. Instead use access_policy block in azurerm_key_vault resource to make sure TF is not trying to create secrets in this key vault before access_policy is applied.

[odee30]

The incorrect object ID as per @AntonChernysh was my issue. Took it from the UI where it is different than if you retrieve the object ID for the underlying service principal account. You can also retrieve this using the PowerShell Get-AzADServicePrincipal command.

[diroussel]

I think this can be closed, as it's working to @odee30, and it's working for me

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!