Azure-cli: AKS arm template deployment failling with "Required parameter servicePrincipalProfile is missing (null)" when no servicePrincipalProfile is provided

Created on 15 Feb 2020  路  14Comments  路  Source: Azure/azure-cli

Describe the bug

When deploying an AKS cluster using ARM templates, if no servicePrincipalProfile is specified a validation exception happens preventing the deployment. According to the documentation, the "servicePrincipalProfile" is an optional field.

This is either an ARM bug or a documentation bug.

Command Name
az group deployment create

Errors:

Azure Error: InvalidTemplateDeployment
Message: The template deployment 'aks' is not valid according to the validation procedure. The tracking id is 'a7dd8808-1302-4c87-a531-6d27b54cdb7e'. See inner errors for details.
Exception Details:
        Error Code: InvalidParameter
        Message: Provisioning of resource(s) for container service tahoma-dev-dalbe1-aks in resource group tahoma-dev-dalbe1-rg failed. Message: {
  "code": "InvalidParameter",
  "message": "Required parameter servicePrincipalProfile is missing (null).",
  "target": "servicePrincipalProfile"
 }. Details:

To Reproduce:

Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

  • _Put any pre-requisite steps here..._
  • az group deployment create --resource-group {} --template-file {} --parameters {} --parameters {}

Expected Behavior

According to the documentation deploying a template without this value should succeed.

Environment Summary

Linux-4.4.0-18362-Microsoft-x86_64-with-debian-buster-sid
Python 3.6.5
Shell: bash

azure-cli 2.0.81

Additional Context


AKS Service Attention

Most helpful comment

[cc: @KaiWalter, @Diastro]

Please see the template below to deploy with MSI:

"resources": [
        {
            "apiVersion": "2020-03-01",
            "dependsOn": [],
            "type": "Microsoft.ContainerService/managedClusters",
            "location": "[parameters('location')]",
            "name": "[parameters('resourceName')]",
            "properties": {
                "kubernetesVersion": "[parameters('kubernetesVersion')]",
                "enableRBAC": "[parameters('enableRBAC')]",
                "dnsPrefix": "[parameters('dnsPrefix')]",
                "agentPoolProfiles": [
                    {
                        "name": "agentpool",
                        "osDiskSizeGB": "[parameters('osDiskSizeGB')]",
                        "count": 3,
                        "vmSize": "Standard_DS2_v2",
                        "osType": "Linux",
                        "storageProfile": "ManagedDisks",
                        "type": "VirtualMachineScaleSets",
                        "mode": "System"
                    }
                ],
                "networkProfile": {
                    "loadBalancerSku": "standard",
                    "networkPlugin": "[parameters('networkPlugin')]"
                },
                "apiServerAccessProfile": {
                    "enablePrivateCluster": "[parameters('enablePrivateCluster')]"
                },
                "addonProfiles": {
                    "httpApplicationRouting": {
                        "enabled": "[parameters('enableHttpApplicationRouting')]"
                    },
                    "omsagent": {
                        "enabled": "[parameters('enableOmsAgent')]",
                        "config": {
                            "logAnalyticsWorkspaceResourceID": "[parameters('omsWorkspaceId')]"
                        }
                    }
                }
            },
            "tags": {},
            "identity": {
                "type": "SystemAssigned"
            }
        }

For MSI, you need to use the identity tag. I was able to get help from the AKS team internally for this. They also suggested exporting the ARM template from Portal before deploying for these properties.

This might be a common usecase, would be great if it got documented.

All 14 comments

HI @qwordy could you pls have a look at this issue firstly to see if it's error in arm template? thanks.

no milestone yet before investigation done.

@qwordy, any update on this?

Hi @qwordy, Do you find anything around it?

It's not a required parameter according the https://github.com/Azure/azure-rest-api-specs/blob/master/specification/containerservice/resource-manager/Microsoft.ContainerService/stable/2020-01-01/managedClusters.json
If you use az aks create, servicePrincipalProfile will be assembled in request body, no matter you specify it or not.
Add service attention to consult AKS people.

Hello, is there an update on this? I'm blocked on deploying AKS cluster without the SPN because of this...

AKS service team should be involved into this.

Same here - I also cannot deploy w/o SPN w/ MSI. Neither from CLI nor with ARM template.

CLI version: 2.4.0
ARM:
"apiVersion": "2020-03-01",
"type": "Microsoft.ContainerService/managedClusters"

[cc: @KaiWalter, @Diastro]

Please see the template below to deploy with MSI:

"resources": [
        {
            "apiVersion": "2020-03-01",
            "dependsOn": [],
            "type": "Microsoft.ContainerService/managedClusters",
            "location": "[parameters('location')]",
            "name": "[parameters('resourceName')]",
            "properties": {
                "kubernetesVersion": "[parameters('kubernetesVersion')]",
                "enableRBAC": "[parameters('enableRBAC')]",
                "dnsPrefix": "[parameters('dnsPrefix')]",
                "agentPoolProfiles": [
                    {
                        "name": "agentpool",
                        "osDiskSizeGB": "[parameters('osDiskSizeGB')]",
                        "count": 3,
                        "vmSize": "Standard_DS2_v2",
                        "osType": "Linux",
                        "storageProfile": "ManagedDisks",
                        "type": "VirtualMachineScaleSets",
                        "mode": "System"
                    }
                ],
                "networkProfile": {
                    "loadBalancerSku": "standard",
                    "networkPlugin": "[parameters('networkPlugin')]"
                },
                "apiServerAccessProfile": {
                    "enablePrivateCluster": "[parameters('enablePrivateCluster')]"
                },
                "addonProfiles": {
                    "httpApplicationRouting": {
                        "enabled": "[parameters('enableHttpApplicationRouting')]"
                    },
                    "omsagent": {
                        "enabled": "[parameters('enableOmsAgent')]",
                        "config": {
                            "logAnalyticsWorkspaceResourceID": "[parameters('omsWorkspaceId')]"
                        }
                    }
                }
            },
            "tags": {},
            "identity": {
                "type": "SystemAssigned"
            }
        }

For MSI, you need to use the identity tag. I was able to get help from the AKS team internally for this. They also suggested exporting the ARM template from Portal before deploying for these properties.

This might be a common usecase, would be great if it got documented.

@naman1901 - thanks, based on your template I rearranged some stuff and now it is deploying

Update on this? I ran into this today as well.

@jongio: Could you share your template?

for MSI make sure to remove servicePrincipalProfile and use:

"identity": {
    "type": "SystemAssigned"
 }

for service principal use:

"servicePrincipalProfile": {
      "clientId": "string",
      "secret": "string"
},

Thanks for answering, Thomas! This should resolve the issue, so closing this for now

I get the same error when creating a cluster via the go sdk. I do have my cluster identity set to system assigned, but it still expects the service principal profile. I guess there is some client helper magic happening that we don't get for free in the sdk?

    future, err := clusterClient.CreateOrUpdate(ctx, clusterGroup, name, containerservice.ManagedCluster{
        Identity: &containerservice.ManagedClusterIdentity{
            Type: containerservice.ResourceIdentityTypeSystemAssigned,
        },
        Location: &location,
    })

I do see the struct for servicePrincipalProfile within the cluster properties, I just don't know what to set it to with system assigned?

Was this page helpful?
0 / 5 - 0 ratings