[BUG] Support for registries with 'AADAuthenticationAsArmPolicy' property set to 'disabled' (Conditional Access)
Opened this issue · 2 comments
Describe the bug
AKS does not handle ACR scope tokens when property AADAuthenticationAsArmPolicy is set to disabled
To Reproduce
Steps to reproduce the behavior:
- disable AADAuthenticationAsArmPolicy in the target registry:
az acr config authentication-as-arm update -r --status disabled - run
az aks check-acr(or any other attempt to authenticate the cluster to the registry)
PS C:\Users\ext.tmanriquev.nttda> az aks check-acr --name aks-eu1-integra-multicanal-desa --resource-group rg-eu1-plat-integra-desa --acr acrseu1integradesa.azurecr.io Merged "aks-eu1-integra-multicanal-desa" as current context in C:\Users\EXTTMA~1.NTT\AppData\Local\Temp\12\tmp8mzt5rds [2024-09-23T19:49:18Z] Checking host name resolution (acrseu1integradesa.azurecr.io): SUCCEEDED [2024-09-23T19:49:18Z] Canonical name for ACR (acrseu1integradesa.azurecr.io): acrseu1integradesa.privatelink.azurecr.io. [2024-09-23T19:49:18Z] Checking managed identity... [2024-09-23T19:49:18Z] Kubelet managed identity client ID: 17e464cb-e6b1-4d5c-be73-98884b0ad911 [2024-09-23T19:49:18Z] Validating managed identity existance: SUCCEEDED [2024-09-23T19:49:18Z] Validating image pull permission: FAILED [2024-09-23T19:49:18Z] ACR acrseu1integradesa.azurecr.io rejected token exchange: ACR token exchange endpoint returned error status: 401. body: {"errors":[{"code":"UNAUTHORIZED","message":"arm aad token disallowed: registry has AADAuthenticationAsArmPolicy disabled"}]}
Expected behavior
AKS needs to be able to support requesting ACR scope tokens in order to support conditional access with a container registry
https://learn.microsoft.com/en-us/azure/container-registry/container-registry-configure-conditional-access
AZ CLI (acr modules) already supports the required change for the scope (here)
ACR's scope is https://containerregistry.azure.net
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):
- CLI Version - any
- Kubernetes version - any
- CLI Extension version [e.g. 1.7.5] if applicable
- Browser [e.g. chrome, safari] is applicable
Additional context
Add any other context about the problem here.
I'm able to reproduce this, though the error message is slightly different (less helpful?) to OPs:
# az aks check-acr --name akstest-2002 --resource-group akstest-2002 --acr akstest2002.azurecr.io
Merged "akstest-2002" as current context in /tmp/tmpnamincq5
[2025-02-20T13:52:19Z] Checking host name resolution (akstest2002.azurecr.io): SUCCEEDED
[2025-02-20T13:52:19Z] Canonical name for ACR (akstest2002.azurecr.io): akstest2002.privatelink.azurecr.io.
[2025-02-20T13:52:19Z] Checking managed identity...
[2025-02-20T13:52:19Z] Kubelet managed identity client ID: 6680bc52-d71a-4a3a-bfa7-441908063e68
[2025-02-20T13:52:19Z] Validating managed identity existance: SUCCEEDED
[2025-02-20T13:52:19Z] Validating image pull permission: FAILED
[2025-02-20T13:52:19Z] ACR akstest2002.azurecr.io rejected token exchange: ACR token exchange endpoint returned error status: 401. body: {"errors":[{"code":"UNAUTHORIZED","message":"token validation failed"}]}
On setting authentication-as-arm back to enabled, the cluster starts working again:
# az aks check-acr --name akstest-2002 --resource-group akstest-2002 --acr akstest2002.azurecr.io
Merged "akstest-2002" as current context in /var/folders/2b/q4blsl254f1dffr8hfgsrt7w0000gn/T/tmpb6epnw_2
[2025-02-20T14:02:04Z] Checking host name resolution (akstest2002.azurecr.io): SUCCEEDED
[2025-02-20T14:02:04Z] Canonical name for ACR (akstest2002.azurecr.io): akstest2002.privatelink.azurecr.io.
[2025-02-20T14:02:04Z] Checking managed identity...
[2025-02-20T14:02:04Z] Kubelet managed identity client ID: 6680bc52-d71a-4a3a-bfa7-441908063e68
[2025-02-20T14:02:04Z] Validating managed identity existance: SUCCEEDED
[2025-02-20T14:02:04Z] Validating image pull permission: SUCCEEDED
[2025-02-20T14:02:04Z]
Your cluster can pull images from akstest2002.azurecr.io!
@cegraybl @brk3 thanks for reporting the issue. we are planning to support acr audience token to avoid the failure when authentication-as-arm is set to true by kubernetes-sigs/cloud-provider-azure#8593. This will be released in AKS soon, AKS release note it.
For this CLI issue, we need another CLI side change to update check-acr, pure client-side work, to use acr audience token as well after AKS officially supports acr audience token.