The value of parameter linuxProfile.ssh.publicKeys.keyData is invalid for AKS cluster creation

[manojazad]

Bicep version 0.16.2

Describe the bug I am trying to create an AKS cluster using bicep. I am trying to set up node linux profile using a rsa ssh key pair for authentication. For generating this key pair, I am using deployment script.

I am getting below error

Inner Errors:
{"code": "InvalidParameter", "message": "Provisioning of resource(s) for container service accl-mgmt-aks-staging-pq in resource group testJapanBuildout failed. Message: The value of parameter linuxProfile.ssh.publicKeys.keyData is invalid. Please see https://aka.ms/aks-naming-rules for more details.. Details: "} 

To Reproduce Below Bicep code can be used

// Generate SSH Key Pair for Uploading to nodes - useful for advance debugging when needed
resource sshKeyGenScript 'Microsoft.Resources/deploymentScripts@2020-10-01' = {
  name: 'sshKeyGenScript-${uniqueString(resourceGroup().id)}'
  location: LOCATION
  kind: 'AzureCLI'
  properties: {
    azCliVersion: '2.45.0'
    timeout: 'PT15M'
    cleanupPreference: 'Always'
    retentionInterval: 'PT1H'
    scriptContent: '''
    ssh-keygen -f aksCluster -t rsa -C azureuser
    privateKey=$(cat aksCluster)
    publicKey=$(cat 'aksCluster.pub')
    json="{\"keyinfo\":{\"privateKey\":\"$privateKey\",\"publicKey\":\"$publicKey\"}}"
    echo "$json" > $AZ_SCRIPTS_OUTPUT_PATH
    '''
  }
}

resource aksUserManagedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2018-11-30' = {
  name: cpAksUamiName
  location: LOCATION
}

// Create the ControlPlane AKS Cluster
resource aksCluster 'Microsoft.ContainerService/managedClusters@2021-10-01' = {
  name: cpAksName
  location: LOCATION
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${aksUserManagedIdentity.id}': {}
    }
  }
  sku: {
    name: 'Basic'
    tier: 'Paid'
  }
  properties: {
    dnsPrefix: cpAksName
    kubernetesVersion: K8S_VERSION
    nodeResourceGroup: aksNodeResourceGroupName
    linuxProfile: {
      adminUsername: ADMIN_USERNAME
      ssh: {
        publicKeys: [
          {
            keyData: sshKeyGenScript.properties.outputs.keyinfo.publicKey
          }
        ]
      }
    }
    networkProfile: {
      networkPlugin: 'azure'
      serviceCidr: '192.168.0.0/16'
      dnsServiceIP: '192.168.0.10'
      loadBalancerSku: 'standard'
      loadBalancerProfile: {
        managedOutboundIPs: {
          count: 1 
        }
        allocatedOutboundPorts: 0 
        idleTimeoutInMinutes: 4
      }
    }
    aadProfile: {
      adminGroupObjectIDs: [
        'XXX-XXX-XXX' /
      ]
      enableAzureRBAC: true
      managed: true
    }
    agentPoolProfiles: [
      {
        name: 'systempool'
        count: 3
        mode: 'System'
        vmSize: SYSTEM_POOL_VM_SIZE
        enableAutoScaling: true
        availabilityZones: [
          '1'
          '2'
          '3'
        ]
        maxPods: 250
        vnetSubnetID: virtualNetworkId
        nodeLabels: {
          mode: 'System'
        }
        osDiskType: 'Ephemeral'
        minCount: 3
        maxCount: 10
        tags: {
          mode: 'system'
        }
      }
    ]
  }
}

Additional context Add any other context about the problem here.

[brwilkinson]

Hi @manojazad

I believe this one is related to the pre-flight validation, which is completed by AKS for the value on publicKeys. This is specifically related to the Resource Provider.

I don't see anything specific in the docs on the referenced page for publicKeys Etc:

• https://aka.ms/aks-naming-rules -->
  • https://learn.microsoft.com/en-us/troubleshoot/azure/azure-kubernetes/aks-common-issues-faq#what-naming-restrictions-are-enforced-for-aks-resources-and-parameters-

---

I was able to make it work... using this workaround

instead of below: which performs the pre-flight validation on the keyData value

      ssh: {
        publicKeys: [
          {
            keyData: sshKeyGenScript.properties.outputs.keyinfo.publicKey
          }
        ]
      }

I was able to use: which skips the preflight validation

      ssh: {
        publicKeys: sshKeyGenScript.properties.outputs.keyInfo.publicKeys
      }

I modified the json output to return the array in publicKeys e.g. keyData.

json="{\"keyInfo\":{\"privateKey\":\"$privateKey\",\"publicKeys\":[{\"keyData\":\"$publicKey\"}]}}"

  scriptContent: '''
    ssh-keygen -f aksCluster -t rsa -C azureuser
    privateKey=$(cat aksCluster)
    publicKey=$(cat 'aksCluster.pub')
    json="{\"keyInfo\":{\"privateKey\":\"$privateKey\",\"publicKeys\":[{\"keyData\":\"$publicKey\"}]}}"
    echo "$json" > $AZ_SCRIPTS_OUTPUT_PATH
  '''

this format

there might be other ways to skip preflight validation as well.

[alex-frankel]

@brwilkinson - is this a false positive for preflight validation? Meaning preflight incorrectly flagged this (likely because AKS team is not handling Template Language Expressions properly? If so, let's move this to bicep-types-az and @manojazad, the next step would be to open a support case and so this can be looked at by the AKS team.

[brwilkinson]

@alex-frankel yes, that appears to be correct, just as you suggested 👍

@manojazad please also test the workaround.

[manojazad]

Yes, It is working for me as well

[dozer75]

@brwilkinson Sorry for bumping in in an "old" issue, but if we're using an sshPublicKeys resource and reference that as keyData it will generate the same error. How can the workaround be applied in this scenario?

Example bicep:

resource sshKey 'Microsoft.Compute/sshPublicKeys@2023-03-01' existing = {
  name: 'ssh-${name}'
}

resource aksCluster 'Microsoft.ContainerService/managedClusters@2023-03-01' = {
  // body omitted to simplify the example
  properties: {
    linuxProfile: {
      adminUsername: 'azureuser'
      ssh: {
        publicKeys: [
          {
            keyData: sshKey.properties.publicKey
          }
        ]
      }
    }
  }
}

[ash3rr]

Facing this same issue while deploying an AKS cluster using Pulumi. Turned out to be a documentation issue related to AKS, refer here: https://github.com/Azure/azure-quickstart-templates/issues/680