If we use --attach-acr from az cli , we don't need to use any service principal for creating AKS cluster.
But terraform requires a mandatory service principal to create AKS which not true anymore from az cli. (What's the use of not having a service principal is a different discussion , like the reason for using managed identities for example)
I think terraform needs to add support for that --attach-acr
# Need to have a flag attach-acr
Hey @esHack,
i had a look into what the azure cli is doing when you pass the --attach-acr flag. The cli simply adds a role assignment to the underlying AKS service principal. The role name is acrpull and the scope is the id of the ACR.
If you want to copy this behavior you could simply also create a role assignment and pass the name of the role mentioned above and the ACR id as scope.
This could be put into the resource itself but is kinda hacky. Downside is that TF isn't able to track if the role assignment was added or if it has to be removed. Custom logic would be needed here which can be avoided very easily.
Keep in mind that in order to create this role assignment you need to have owner permissions or the User Access Administrator role for the subscription (afair).
@esHack Did you get any update on the attach-acr stuff in terraform or you are using the role assignment only ?
@r0bnet : What is quoted as AKS service principal, the one of server side or client one ??
hi @esHack
Thanks for opening this issue.
As @r0bnet has mentioned this should be possible to achieve by assigning a role assignment, which can be achieved in Terraform using the azurerm_role_assignment resource. Whilst the Azure Portal/CLI occasionally offer helper flags such as this, from Terraform's side we try to match the API - in particular in this instance doing so allows us to ensure that were a user to destroy the cluster that the associated Role Assignment would also be removed (since the azurerm_role_assignment resource would get deleted during a terraform destroy).
Since it should be possible to achieve this using the azurerm_role_assignment resource I'm going to close this issue for for the moment - but would you be able to take a look and see if that works for you?
Thanks!
Hey all,
I just came across this issue.
I fixed this using the already mentioned azurerm_role_assignment resource. A short example:
resource "azurerm_role_assignment" "acr" {
scope = azurerm_container_registry.acr.id
role_definition_name = "acrpull"
principal_id = azuread_service_principal.aks-aad.object_id
depends_on = [
azurerm_container_registry.acr,
azuread_application.aks
]
}
"azurerm_container_registry.acr.id" is the ID of my ACR. "azuread_service_principal.aks-aad.object_id" the Object ID of the AKS SPN.
It`s important to create the ACR as well as the Role assignment before creating the AKS itself.
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!
Most helpful comment
Hey all,
I just came across this issue.
I fixed this using the already mentioned azurerm_role_assignment resource. A short example:
"azurerm_container_registry.acr.id" is the ID of my ACR. "azuread_service_principal.aks-aad.object_id" the Object ID of the AKS SPN.
It`s important to create the ACR as well as the Role assignment before creating the AKS itself.