Terraform-provider-azurerm: BUG azurerm_role_assignment is not working as expected

[aksakalli]

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 AzureRM Provider) Version

Terraform v0.12.10

Affected Resource(s)

• azurerm_role_assignment

Terraform Configuration Files

I am trying to give my aks pull rights for my container registry.

provider "azurerm" {
  version = "~> 1.35.0"
}

resource "azurerm_role_assignment" "cr_cluster_role" {
  principal_id         = "11111111-111111111-1111-111111111111"
  role_definition_name = "acrpull"
  scope                = "/subscriptions/00000000-000000000-0000-000000000000/resourceGroups/myteam-k8s-resources/providers/Microsoft.ContainerRegistry/registries/myteam"
}

I am masking my principal id & subscription id through out this explanation but I kept the other UIDs as shown for the output.

Debug Output

[DEBUG] AzureRM Request: 
PUT //subscriptions/00000000-000000000-0000-000000000000/resourceGroups/myteam-k8s-resources/providers/Microsoft.ContainerRegistry/registries/myteam/providers/Microsoft.Authorization/roleAssignments/f7c88018-30fa-911d-75ac-426c97f1a788?api-version=2018-09-01-preview HTTP/1.1
Host: management.azure.com
User-Agent: Go/go1.12.6 (amd64-linux) go-autorest/v13.0.0 Azure-SDK-For-Go/v33.2.0 authorization/2018-09-01-preview HashiCorp Terraform/0.12.10 (+https://www.terraform.io) terraform-provider-azurerm/1.35.0
Content-Length: 229
Content-Type: application/json; charset=utf-8
X-Ms-Correlation-Request-Id: ecc1645e-5576-6270-840b-f860809fd86f
Accept-Encoding: gzip

{"properties":{"roleDefinitionId":"/subscriptions/00000000-000000000-0000-000000000000/providers/Microsoft.Authorization/roleDefinitions/7f951dda-4ed3-4680-a7ca-43fe172d538d","principalId":"11111111-111111111-1111-111111111111"}}
[DEBUG] AzureRM Response for https://management.azure.com//subscriptions/00000000-000000000-0000-000000000000/resourceGroups/myteam-k8s-resources/providers/Microsoft.ContainerRegistry/registries/myteam/providers/Microsoft.Authorization/roleAssignments/f7c88018-30fa-911d-75ac-426c97f1a788?api-version=2018-09-01-preview: 
HTTP/2.0 400 Bad Request
Content-Length: 163
Cache-Control: no-cache
Content-Type: application/json; charset=utf-8
Date: Thu, 17 Oct 2019 11:51:56 GMT
Expires: -1
Pragma: no-cache
Set-Cookie: x-ms-gateway-slice=Production; path=/; secure; HttpOnly
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Ms-Correlation-Request-Id: ecc1645e-5576-6270-840b-f860809fd86f
X-Ms-Ratelimit-Remaining-Subscription-Writes: 1168
X-Ms-Request-Id: d4b9439f-ba04-4402-80d0-ac0104eca7e7
X-Ms-Routing-Request-Id: UKWEST:20191017T115157Z:80ff53b6-2c9b-4752-be15-49acf4ed98b9

{"error":{"code":"PrincipalNotFound","message":"Principal 6d4e1aaadab54700aed6eba57c212cb0 does not exist in the directory 22222222-222222222-2222-222222222222."}}

Panic Output

Error: authorization.RoleAssignmentsClient#Create: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="PrincipalNotFound" Message="Principal 6d4e1aaadab54700aed6eba57c212cb0 does not exist in the directory 22222222-222222222-2222-222222222222."

  on main.tf line 5, in resource "azurerm_role_assignment" "cr_cluster_role":
   5: resource "azurerm_role_assignment" "cr_cluster_role" {

The principal id is completely different than my input and 22222222-222222222-2222-222222222222 is actually my tenantId.

Expected Behavior

This role assignment works just fine when I use the az cli as:

$ az role assignment create \
  --assignee 11111111-111111111-1111-111111111111 \
  --role acrpull \
  --scope /subscriptions/00000000-000000000-0000-000000000000/resourceGroups/myteam-k8s-resources/providers/Microsoft.ContainerRegistry/registries/myteam

Actual Behavior

It gives an error when I do the same thing with azurerm_role_assignment.

Steps to Reproduce

1. terraform apply

[WodansSon]

I believe you are hitting the Azure AD replication lag, have you tried using the new attribute skip_service_principal_aad_check set to true?

resource "azurerm_role_assignment" "cr_cluster_role" {
  principal_id                     = "11111111-111111111-1111-111111111111"
  role_definition_name             = "acrpull"
  scope                            = "/subscriptions/00000000-000000000-0000-000000000000/resourceGroups/myteam-k8s-resources/providers/Microsoft.ContainerRegistry/registries/myteam"
  skip_service_principal_aad_check = true
}

[aksakalli]

I tried skip_service_principal_aad_check = true and resulted with Resources: 0 added, 0 changed, 0 destroyed. although in the planning it stated : Plan: 1 to add, 0 to change, 0 to destroy.. Still the k8s gives ErrImagePull.

I retried it as terraform destroy & terraform apply now I am getting:

Error: authorization.RoleAssignmentsClient#Create: Failure responding to request: StatusCode=409 -- Original Error: autorest/azure: Service returned an error. Status=409 Code="RoleAssignmentExists" Message="The role assignment already exists."

  on main.tf line 5, in resource "azurerm_role_assignment" "cr_cluster_role":
   5: resource "azurerm_role_assignment" "cr_cluster_role" {

I can not see this assignment and my aks is still not authorize to pull images.

[WodansSon]

Hi @aksakalli,

Yes, now that some time has passed (normally between 2 to 5 minutes) AD replication has pushed the role assignment into AD. Which means if you are going to be using the same principal id the role assignment block of your configuration should no longer be necessary.

[WodansSon]

@aksakalli,

I'm going to go ahead and close this issue as there has not been any response for 15 days so I am assuming that this issue has been addressed. If not please feel free to contact me and I will be happy to work with you further. Cheers.

[aksakalli]

the problem persists, I still can not assign roles via azurerm_role_assignment.

[vinodhbasavani]

I am also facing the issues with this.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

[tombuildsstuff]

@aksakalli looks like @WodansSon is waiting for you to reply to this comment?

[aksakalli]

It does not work despite skip_service_principal_aad_check = true, it is still not working for

provider "azurerm" {
  version = "~> 1.35.0"
}

resource "azurerm_role_assignment" "cr_cluster_role" {
  principal_id         = "11111111-111111111-1111-111111111111"
  role_definition_name = "acrpull"
  scope                = "/subscriptions/00000000-000000000-0000-000000000000/resourceGroups/myteam-k8s-resources/providers/Microsoft.ContainerRegistry/registries/myteam"
  skip_service_principal_aad_check = true
}

but the az CLI works:

$ az role assignment create \
  --assignee 11111111-111111111-1111-111111111111 \
  --role acrpull \
  --scope /subscriptions/00000000-000000000-0000-000000000000/resourceGroups/myteam-k8s-resources/providers/Microsoft.ContainerRegistry/registries/myteam

[aksakalli]

Finally, I figured out the problem. I am using this module to create my service principle and it creates a resource like:

{
    "app_role_assignment_required": false,
    "application_id": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy",
    "display_name": "myapplication-k8s-sp",
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "oauth2_permissions": [
    {
        "admin_consent_description": "...",
        "admin_consent_display_name": "...",
        "id": "...",
        "is_enabled": true,
        "type": "User",
        "user_consent_description": "...",
        "user_consent_display_name": "...",
        "value": "..."
    }
    ],
    "object_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tags": []
}

In the role assignment, if I use object_id (id the same), it works but it does not work if I use application_id which is the same as my cluster's servicePrincipalProfile.clientId. The weird case is that, the az CLI can figure out this application_id and the assignment works perfectly fine but not with the Terraform provider azurerm_role_assignment. In fact, application_id is the recommended way to set AcrPull permission for your cluster in this guide.

Btw I did this changes in more recent versions:

$ terraform --version
Terraform v0.12.20
+ provider.azuread v0.7.0
+ provider.azurerm v1.42.0
+ provider.random v2.2.1

[WodansSon]

@aksakalli Sorry for the late reply, I've been head down in other areas. I'm glad you found a resolution for the issue, in your opinion do you feel there is anything else to be done here? Do you feel the name of the attribute is confusing? Do you feel if we renamed the attribute from principal_id to principal_object_id it would be more intuitive as to the expected value here? The documentation notes that The Principal ID is also known as the Object ID (ie not the "Application ID" for applications).

[aksakalli]

I was expecting identical behavior to az role assignment create. I should have noticed the docs, it is really clear.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!