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

  1. 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)

Most upvoted comments

Ok, I found a workaround, which is adding a delay after the service principal creation. I did it adding a null resource:

resource "null_resource" "delay_after_sp_created" {
  provisioner "local-exec" {
    command = "sleep 60"
  }
  triggers = {
    "before" = azuread_service_principal_password.k8s.value
  }
}

And then adding a dependency for it at my cluster resource:

resource "azurerm_kubernetes_cluster" "foo" {
  depends_on = ["null_resource.delay_after_sp_created"]
}

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.

* azurerm_kubernetes_cluster.aks: Error creating Managed Kubernetes Cluster "abc999" 
(Resource Group "zyx123"): 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: ********\\r\\nCorrelation ID: ********\\r\\nTimestamp: 2019-11-13 
16:49:19Z\",\"error_codes\":[7000215],\"timestamp\":\"2019-11-13 
16:49:19Z\",\"trace_id\":\"*********\",\"correlation_id\":\"*******\",\"error_uri\":
\"https://login.microsoftonline.com/error?code=7000215\"})"

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 and azuread_service_principal, since v0.4.0, and for azuread_application_password and azuread_service_principal_password, since v0.5.0

So, 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