CODEWITHSUNDEEP
azureterraformazure-keyvaultterraform-provider-azure
Alssanro
Alssanro

Reputation: 175

My Terraform Service Principal gets a 403 access error on Key Vault even though I added an access policy for it

I'm terraforming a Key Vault through Terraform. I'm also adding a secret into that Key Vault. Terraform uses a service principal. This is the error I get :

Error: checking for presence of existing Secret "saterradev-access-key" (Key Vault "https://mykv.vault.azure.net/"): keyvault.BaseClient#GetSecret: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="Forbidden" Message="The user, group or application 'appid=2c8...;iss=https://sts.windows.net/a43...' does not have secrets get permission on key vault 'mykvv;location=francecentral'. For help resolving this issue, please see https://go.microsoft.com/fwlink/?linkid=2125287" InnerError={"code":"AccessDenied"}

The given appid with no authorization is the same I added in the access policy (I checked multiple times).

I do not understand why, I set up an access policy for my service principal with depends on while creating the secret. Here is the Terraform code:

data "azurerm_client_config" "current" {}

resource "azurerm_key_vault" "key_vault" {
  name                       = "kv-${local.resource_name}"
  location                   = azurerm_resource_group.rg_project.location
  resource_group_name        = azurerm_resource_group.rg_project.name
  tenant_id                  = data.azurerm_client_config.current.tenant_id
  soft_delete_retention_days = 7
  sku_name                   = "standard"
  tags                       = var.tags
}

# give access to the SP of Terraform (else denied access to create secrets)
resource "azurerm_key_vault_access_policy" "terraform_sp_access" {
  key_vault_id = azurerm_key_vault.key_vault.id
  tenant_id    = data.azurerm_client_config.current.tenant_id
  object_id    = data.azurerm_client_config.current.client_id # use the client id (for SP) instead of the object id

  key_permissions = [
    "get", "list", "update", "create", "import", "delete", "recover", "backup", "restore",
  ]

  secret_permissions = [
    "get", "list", "delete", "recover", "backup", "restore", "set",
  ]

  certificate_permissions = [
    "get", "list", "update", "create", "import", "delete", "recover", "backup", "restore", "deleteissuers", "getissuers", "listissuers", "managecontacts", "manageissuers", "setissuers",
  ]
}

# give access to secrets to the managed identity of the function app
resource "azurerm_key_vault_access_policy" "azure_function_access" {
  key_vault_id = azurerm_key_vault.key_vault.id
  tenant_id    = data.azurerm_client_config.current.tenant_id
  object_id    = azurerm_function_app.func_linux_python.identity.0.principal_id

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

# store the main account storage primary access key (to be used when managed identity is not available)
resource "azurerm_key_vault_secret" "primary_account_storage_access_key" {
  key_vault_id = azurerm_key_vault.key_vault.id
  name         = "${azurerm_storage_account.main_storage.name}-access-key"
  value        = azurerm_storage_account.main_storage.primary_access_key
  depends_on   = [azurerm_key_vault_access_policy.terraform_sp_access]
}

Sometimes the deploy works, sometimes it doesn't. I cannot figure why. I'm hinting towards the default soft-delete nature of Key Vault?

thank you

Upvotes: 3

Views: 13187

Answers (3)

DevO43
DevO43

Reputation: 1

Not sure if anyone is affected by this, but when i had this issue i solved it by analysing the permission model and method used by Key Vault.

Sometimes It could Vault Access Policy or RBAC.

If it's the first one, then you need to use access policies, it's the only way to give the service principal access. You'll see it on the left side you select access policy select a template or use your own when you create one.

if it's the former then you have to use Access Control IAM. being handled by RBAC thats the only way

Good luck on your Cloud Work :)

Upvotes: 0

Pete
Pete

Reputation: 1

Was running into the same random behavior on an older azurerm provider version and TF 1.0.1.

Upgraded to latest versions (TF v.1.0.11 and azurerm 2.88.1) and both the KV creation and deletion were successful without issues.

Upvotes: 0

Andriy Bilous
Andriy Bilous

Reputation: 2522

You should use data.azurerm_client_config.current.object_id instead of data.azurerm_client_config.current.client_id in your Terraform resource "azurerm_key_vault_access_policy" "terraform_sp_access"

resource "azurerm_key_vault_access_policy" "terraform_sp_access" {
  key_vault_id = azurerm_key_vault.key_vault.id
  tenant_id    = data.azurerm_client_config.current.tenant_id
  object_id    = data.azurerm_client_config.current.object_id

  key_permissions = [
    "get", "list", "update", "create", "import", "delete", "recover", "backup", "restore",
  ]

  secret_permissions = [
    "get", "list", "delete", "recover", "backup", "restore", "set",
  ]

  certificate_permissions = [
    "get", "list", "update", "create", "import", "delete", "recover", "backup", "restore", "deleteissuers", "getissuers", "listissuers", "managecontacts", "manageissuers", "setissuers",
  ]
}

Here is a reference to azurerm Terraform provider Go tests.

https://github.com/terraform-providers/terraform-provider-azurerm/blob/be97ca6ab3913220a16eadb76fb7cbdccf711dff/azurerm/internal/services/keyvault/key_vault_access_policy_resource_test.go#L176

Upvotes: 4

Related Questions