简体   繁体   English

我的 Terraform 服务主体在 Key Vault 上收到 403 访问错误,即使我为其添加了访问策略

[英]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.我正在通过 Terraform 对 Key Vault 进行改造。 I'm also adding a secret into that Key Vault.我还在该 Key Vault 中添加了一个秘密。 Terraform uses a service principal. Terraform 使用服务主体。 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.错误:检查是否存在现有秘密“saterradev-access-key”(密钥库“https://mykv.vault.azure.net/”):keyvault.BaseClient#GetSecret:响应请求失败:StatusCode=403 --原始错误:autorest/azure:服务返回错误。 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"} Status=403 Code="Forbidden" Message="用户、组或应用程序 'appid=2c8...;iss=https://sts.windows.net/a43...' 没有秘密获得密钥权限vault 'mykvv;location=francecentral'。有关解决此问题的帮助,请参阅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).没有授权的给定appid与我在访问策略中添加的相同(我检查了多次)。

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:这是 Terraform 代码:

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?我在暗示 Key Vault 的默认软删除性质?

thank you谢谢你

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"您应该在 Terraform 资源"azurerm_key_vault_access_policy" "terraform_sp_access"使用data.azurerm_client_config.current.object_id而不是data.azurerm_client_config.current.client_id

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.这是对 azurerm Terraform provider Go 测试的参考。

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

Was running into the same random behavior on an older azurerm provider version and TF 1.0.1.在较旧的 azurerm 提供程序版本和 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.升级到最新版本(TF v.1.0.11 和 azurerm 2.88.1),KV 创建和删除都成功没有问题。

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.不确定是否有人受此影响,但当我遇到此问题时,我通过分析权限 model 和 Key Vault 使用的方法解决了这个问题。

Sometimes It could Vault Access Policy or RBAC.有时它可以保管库访问策略或 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.您将在左侧看到它 select 访问策略 select 模板或在创建模板时使用您自己的模板。

if it's the former then you have to use Access Control IAM.如果是前者,那么您必须使用访问控制 IAM。 being handled by RBAC thats the only way由 RBAC 处理,这是唯一的方法

Good luck on your Cloud Work:)祝你的云工作好运:)

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 为什么我的服务主管无法访问我的密钥保险库? - Why does my service principal not have access to my key vault? Terraform 使用 Azure Key Vault 应用与访问策略相关的抛出错误 - Terraform Apply throwing error related to access policy with Azure Key Vault Terraform - 如何获取 azurerm 密钥保管库访问策略的应用服务对象 ID? - Terraform - How to get App Service object id for azurerm key vault access policy? Terraform azurerm_key_vault - 访问策略引发错误 - Terraform azurerm_key_vault - Access policy raising errors 在 key_vault 资源中附加多个 key_vault_access_policy 时出错 - 资源需要导入到 State - Terraform / Azure - Error when appending multiple key_vault_access_policy in a key_vault resource - resource needs to be imported into the State - Terraform / Azure 当我重新部署 terraform 代码时,Azure 数据工厂密钥保管库访问策略被删除? - Azure Data Factory key vault access policy is getting deleted when I do redeploy of terraform code? 无法在使用我的机器人资源自动创建的密钥保管库中查看机密 - 即使使用新的访问策略 - Unable to see secrets -even with new access policy- in key vault automatically created with my bot resource 提供Terraform Service的主要贡献者,但从Key Vault中删除 - Give Terraform Service Principal Contributor but remove from Key Vault 在 PowerShell 中设置 Azure Key Vault 访问策略时出错 - Error Setting Azure Key Vault Access Policy in PowerShell Terraform Azure Key Vault Secret 不依赖于 access_policy - Terraform Azure Key Vault Secret does not depend_on access_policy
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM