Open neilmca-inc opened 2 years ago
Any news on this one ? I'm experiencing this aswell
If I may add to this issue : it is currently impossible to correctly set an access policy for an app registration service principal using terraform azurerm provider
When you use the appreg clientID as object_id, it results in what @neilmca-inc showed in the issue report.
If you use its actual objectID in the object_id field, the permission this time correctly "resolves" the SPN, but the access policy isn't working when you connect using cliendID/clientSecret
If you use the objectID in object_id field, and the clientID in application_id field, you end up with a compound identity (https://learn.microsoft.com/en-us/azure/key-vault/general/security-features#key-vault-authentication-options) and are required to use OBO flow.
It appears to me that there is no way right now using terraform azurerm provider to end up with an access policy correctly set as when using the portal if you are assigning the policy to a service principal
Is there any ETA on fixing this ? Anything we can provide to help solving it ? I'm using 3.53.0 azurerm provider version right now
Any update on this issue? This came back today to bite me hard
Is there an existing issue for this?
Community Note
Terraform Version
1.2.5
AzureRM Provider Version
3.24.0
Affected Resource(s)/Data Source(s)
azurerm_key_vault_access_policy
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
Appears as an APPLICATION in the Key Vault access policy
Actual Behaviour
Appears as an UNKNOWN in the Key Vault access policy
If I manually remove the UNKNOWN and use the same ClientID it resolves correctly as an APPLICATION and it works
In this example it is listed in Azure AD as an Enterprise Application...
...which comes from a Managed Identity...
Steps to Reproduce
Creates a Key Vault and very small AKS cluster
Even if you manually add the ClientID in Terraform afterwards in the main.tf file - e.g.
...it will still enter it as UNKNOWN.
The object_id is correctly populated in the .tfstate file output under nested object key_vault_secrets_provider/secret_identity/client_id for azurerm_kubernetes_cluster
Important Factoids
I don't believe this is anything to do with AKS - given it is a duplicate of https://github.com/hashicorp/terraform-provider-azurerm/issues/6021 then I believe the fault is with the azurerm_key_vault_access_policy resource
References
This references the closed case https://github.com/hashicorp/terraform-provider-azurerm/issues/6021 which was closed without resolution. It is still an issue