Docs: Clarification required regarding Disabling Local Accounts

[rbjorklin]

I've been trying to disable local accounts following this section in the documentation. However when doing this I'm met with:

❯ k get ManagedCluster
NAME   READY   SEVERITY   REASON   MESSAGE
dev2   False   Warning    Failed   extension failed to produce resources for export: failed listing admin credentials: POST https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-dev-aks-westus3/providers/Microsoft.ContainerService/managedClusters/myCluster/listClusterAdminCredential...

This leads me to believe I also have to grant Azure Kubernetes Service Cluster Admin Role.

I have two questions:

• Could you confirm the above is expected and just missing from the documentation as it stands?
• Does the suggested credential ${CLUSTER_NAME}-user-kubeconfig have to be specified somewhere or does capz know to pick it up?

[nojnhuh]

• Could you confirm the above is expected and just missing from the documentation as it stands?

Does the full message indicate something like "you don't have permission" or something closer to "you can't do this because local accounts are disabled"?

Some role that grants Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action or Microsoft.ContainerService/managedClusters/listClusterUserCredential/action is required, depending on if your ManagedCluster specifies one or both of spec.operatorSpec.secrets.adminCredentials and spec.operatorSpec.secrets.userCredentials.

Admin credentials can't be fetched when local accounts are disabled by design, so you should specify only spec.operatorSpec.secrets.userCredentials in your ManagedCluster in that case.

Those are all general AKS requirements though, not specific to CAPZ. We try not to reproduce AKS-general things in the CAPZ docs.

• Does the suggested credential ${CLUSTER_NAME}-user-kubeconfig have to be specified somewhere or does capz know to pick it up?

The name and key of the secret in spec.operatorSpec.secrets.userCredentials or spec.operatorSpec.secrets.adminCredentials don't need to match anything else. CAPZ uses that directly to find the secret.

[rbjorklin]

This is the error I'm seeing: "Getting static credential is not allowed because this cluster is set to disable local accounts."

Admin credentials can't be fetched when local accounts are disabled by design, so you should specify only spec.operatorSpec.secrets.userCredentials in your ManagedCluster in that case.

Unless I'm not mistaken this is not possible as the adminCredentials are mutated into place by this provider?

[nojnhuh]

Admin credentials can't be fetched when local accounts are disabled by design, so you should specify only spec.operatorSpec.secrets.userCredentials in your ManagedCluster in that case.

Unless I'm not mistaken this is not possible as the adminCredentials are mutated into place by this provider?

Right above there, the function exits early code when either userCredentials or adminCredentials are defined. CAPZ only populates the adminCredentials when neither is already defined in the ManagedCluster in the AzureASOManagedControlPlane.

[rbjorklin]

Right above there, the function exits early code when either userCredentials or adminCredentials are defined.

Ah, you're absolutely correct!

Did the specific error "Getting static credential is not allowed because this cluster is set to disable local accounts." tell you anything new?

Also should the credential be ${CLUSTER_NAME}-user-aso as per this?

[nojnhuh]

Did the specific error "Getting static credential is not allowed because this cluster is set to disable local accounts." tell you anything new?

I don't think so. That expectation is already documented.

Also should the credential be ${CLUSTER_NAME}-user-aso as per this?

Not necessarily, that's totally independent of AzureASOManagedControlPlanes.