PMFR4PLTFND-1316: add rbac_aad_azure_rbac_enabled var

[ajeffowens]

Ran two tests. One with rbac_aad_azure_rbac_enabled set to true, which produced an aks cluster with:

Authentication and Authorization
Microsoft Entra ID authentication with Azure RBAC

and another with the variable omitted entirely, which produced an aks cluster with:

Authentication and Authorization
Microsoft Entra ID authentication with Kubernetes RBAC

which is consistent with current default behavior

[riragh]

Few comments about this PR:

• Starting Kubernetes v1.26, the azure auth provider was removed from the kubectl binary, so user would need an alternative method to be able to authenticate to AKS. With Azure RBAC enabled, for non-interactive seamless authentication (which also helps DAC) we would need to use kubelogin. I don't see any code around that.
• We would need some documentation on how to authenticate as using the kubeconfig generated by IAC will return error.
• Additionally, if my memory serves me well, we need to disable local_accounts when using Azure RBAC.

[ajeffowens]

The admin kubeconfig is always generated by IAC regardless of the create_static_kubeconfig or rbac_aad_enabled settings, with its behavior solely controlled by create_static_kubeconfig. When set to false, the kubeconfig uses a client certificate for system:masters (local admin account), and when set to true, it uses a service account token tied to cluster-admin. Azure RBAC doesn’t impact this behavior as it functions as an additional layer on top of Kubernetes RBAC, primarily enabling access control through Azure role assignments rather than in-cluster RBAC.

The key advantage of Azure RBAC is centralized management at the management group level.

Local accounts are independent of RBAC settings but must be enabled for create_static_kubeconfig=false to work correctly, while disabling them should not affect service account tokens.

Note - when Azure RBAC is enabled, the rbac_aad_admin_group_object_ids setting becomes irrelevant but does not cause errors.