terraform-provider-azuread: Invalid Credentials in ServicePrincipalProfile
Creating an Azure Kubernetes Cluster failed due to:
The credentials in ServicePrincipalProfile were invalid
See below.
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave “+1” or “me too” comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Terraform (and AzureAD Provider) Version
Terraform v0.12.5
- provider.azuread v0.5.0
- provider.azurerm v1.31.0
- provider.random v2.1.2
Affected Resource(s)
azurerm_kubernetes_cluster azuread_service_principal azuread_service_principal_password
Terraform Configuration Files
variable "agent_count" {
default = 3
description = "The amount of agents to provision"
}
variable "kubernetes_version" {
default = "1.13.5"
description = "The version of kubernetes to be installed"
}
variable "tag" {
description = "The tag name for accounts created in this stack"
}
variable "machine_type" {
default = "Standard_DS2_v2"
description = "The type of machine to provision"
}
variable "location" {
default = "westeurope"
description = "The location/region where resources should be provisioned"
}
locals {
cluster_name = "cpe-demo-${var.tag}-k8s"
dns_prefix = "cpe-demo-${var.tag}-k8s"
resource_group = "cpe-demo-${var.tag}-k8s-rg"
service_principal = "cpe-demo-${var.tag}-sp"
agent_name = "${var.tag}agent"
}
provider "azurerm" {
version = "=1.31.0"
}
provider "azuread" {
version = "=0.5.0"
}
resource "azurerm_resource_group" "aks_resourcegroup" {
name = local.resource_group
location = var.location
}
resource "azuread_application" "aks_azuread_application" {
name = local.service_principal
homepage = "https://cpe-demo-${var.tag}"
identifier_uris = ["https://cpe-demo-${var.tag}"]
reply_urls = ["https://cpe-demo-${var.tag}"]
available_to_other_tenants = false
oauth2_allow_implicit_flow = true
}
resource "azuread_service_principal" "aks_azuread_service_principal" {
application_id = azuread_application.aks_azuread_application.application_id
}
resource "random_string" "service_principal_password_value" {
length = 20
special = false
}
resource "azuread_service_principal_password" "service_principal_password" {
service_principal_id = azuread_service_principal.aks_azuread_service_principal.id
value = random_string.service_principal_password_value.result
end_date = "2020-01-01T01:02:03Z"
}
resource "azurerm_kubernetes_cluster" "aks" {
name = local.cluster_name
location = azurerm_resource_group.aks_resourcegroup.location
resource_group_name = azurerm_resource_group.aks_resourcegroup.name
dns_prefix = local.dns_prefix
kubernetes_version = var.kubernetes_version
agent_pool_profile {
name = local.agent_name
count = var.agent_count
vm_size = var.machine_type
os_type = "Linux"
os_disk_size_gb = 30
}
service_principal {
client_id = azuread_service_principal.aks_azuread_service_principal.application_id
client_secret = azuread_service_principal_password.service_principal_password.value
}
}
Expected Behavior
The Kubernetes cluster should have been created with valid service principal credentials
Actual Behavior
Plan: 6 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
random_string.service_principal_password_value: Creating...
random_string.service_principal_password_value: Creation complete after 0s [id=none]
azuread_application.aks_azuread_application: Creating...
azurerm_resource_group.aks_resourcegroup: Creating...
azurerm_resource_group.aks_resourcegroup: Creation complete after 1s [id=/subscriptions/9e6b1432-c830-41fb-9c63-b1de69af46dd/resourceGroups/cpe-demo-a-k8s-rg]
azuread_application.aks_azuread_application: Still creating... [10s elapsed]
azuread_application.aks_azuread_application: Creation complete after 11s [id=4ad4bd64-e414-4b4f-9a89-ca9feaa8bcc9]
azuread_service_principal.aks_azuread_service_principal: Creating...
azuread_service_principal.aks_azuread_service_principal: Still creating... [10s elapsed]
azuread_service_principal.aks_azuread_service_principal: Creation complete after 10s [id=c88cf08d-cf44-4109-a9b7-e116ebe69a3d]
azuread_service_principal_password.service_principal_password: Creating...
azuread_service_principal_password.service_principal_password: Creation complete after 0s [id=c88cf08d-cf44-4109-a9b7-e116ebe69a3d/629b353c-8143-a4bc-cca6-e9293b0a62aa]
azurerm_kubernetes_cluster.aks: Creating...
Error: Error creating/updating Managed Kubernetes Cluster "cpe-demo-a-k8s" (Resource Group "cpe-demo-a-k8s-rg"): containerservice.ManagedClustersClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="BadRequest" Message="The credentials in ServicePrincipalProfile were invalid. Please see https://aka.ms/aks-sp-help for more details. (Details: adal: Refresh request failed. Status Code = '401'. Response body: {\"error\":\"invalid_client\",\"error_description\":\"AADSTS7000215: Invalid client secret is provided.\\r\\nTrace ID: 65739d36-0ff1-4a83-9de9-d4c87e791400\\r\\nCorrelation ID: fc3a2565-a5ab-4c7d-9b5b-c7d7683dab72\\r\\nTimestamp: 2019-07-24 11:55:59Z\",\"error_codes\":[7000215],\"timestamp\":\"2019-07-24 11:55:59Z\",\"trace_id\":\"65739d36-0ff1-4a83-9de9-d4c87e791400\",\"correlation_id\":\"fc3a2565-a5ab-4c7d-9b5b-c7d7683dab72\"})"
on main.tf line 37, in resource "azurerm_kubernetes_cluster" "aks":
37: resource "azurerm_kubernetes_cluster" "aks" {
Steps to Reproduce
terraform apply
References
https://github.com/terraform-providers/terraform-provider-azuread/issues/4
This issue raised a concern that the delay before a service principal became usable. This seemed to be resolved by PR #86
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 10
- Comments: 17 (3 by maintainers)
Ok, I found a workaround, which is adding a delay after the service principal creation. I did it adding a null resource:
And then adding a dependency for it at my cluster resource:
This works, but it is a terrible workaround. This has to be fixed.
Also, there a discussion to help make the workaround less painful by adding a delay resource, so it will be ugly, but not horrible: https://github.com/hashicorp/terraform/issues/19243
Yeah, this definitely still occurs in the latest version. We’re experiencing this intermittently in provisioning AKS clusters.
Please let me know what I could do to assist in resolving the issue. Is this a problem just on the provider side or is this an API issue?
Hi @giggio, these mitigations have been in place for some time. For
azuread_application
andazuread_service_principal
, since v0.4.0, and forazuread_application_password
andazuread_service_principal_password
, since v0.5.0So, looking at Microsoft’s response in azure/aks#1316, it looks like the provider could attempt to retry this for some time before declaring the principal invalid and the resource failed. An artificial delay of 15s has been enough for me every time in my CI pipeline.
I guess my question is if we can update the service principal password resource to delay until we know that the password has been committed to AD?
I was just able to reproduce this again, so definitely still happening as of version 0.6 azuread