Add Azure AAD/EntraID access settings

[viniciusdc]

Reference Issues or PRs

What does this implement/fix?

Put a x in the boxes that apply

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds a feature)
• Breaking change (fix or feature that would cause existing features not to work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build related changes
• Other (please describe):

Testing

• Did you test the pull request locally?
• Did you add new tests?

How to test this PR?

• deploy a fresh instance of Nebari on Azure
• Create a Group in Azure through the console, which will be considered the Owner/Admin group for the access settings of RBAC;
• Set the appropriate new field details in your nebari-config.yaml with the respective groupId from above, e.g.:

azure:
  aad_access_control:
    azure_rbac_enabled: true
    admin_group_object_ids:
      -  ********

• validate the Azure RBAC settings were applied under the security tab under your k8s cluster details in the azure console
• For extra steps you can use https://deploy-preview-551--nebari-docs.netlify.app/docs/how-tos/configure-azure-rbac#what-is-azure-rbac

Any other comments?

[viniciusdc]

I just need to rename the enabled field since its misleading, its intent is to enable the usage of RBAC roles from Azure instead of the default kuberntes behavior which is an authorization change, works different then the others enabled flags on nebari right now (this does not refer to the actual toggle of this property in the cluster)

[dcmcand]

@viniciusdc is this ready for review?

[viniciusdc]

I discovered an issue with the previous azure_addon_policy settings: Terraform did not expect a null value in one case. This PR will also address that oversight.

Subsequently, while re-testing on a different machine (with an Azure RBAC deployment already confirmed to work), I encountered a new strange error related to the kube_config artifact in the AKS cluster resource. It returned a key error when retrieving the Kubernetes credentials from the cluster. This may indicate the need to use the exec block for the Kubernetes provider when AAD/RBAC is enabled. I’m still investigating the problem, as this behavior wasn’t observed before.

[tofu]: │ Error: Invalid index
[tofu]: │ 
[tofu]: │   on modules/kubernetes/outputs.tf line 4, in module "k8s_credentials":
[tofu]: │    4:   kube_admin_config  = azurerm_kubernetes_cluster.main.kube_admin_config[0]
[tofu]: │ 
[tofu]: │ The given key does not identify an element in this collection value.
[tofu]: ╵
[tofu]: Releasing state lock. This may take a few moments...

[viniciusdc]

My assumption seems correct; after manually enabling local_accounts through the Azure portal, the deployed could continue without encountering the problem above. I already have a possible remedy for this scenario, which I will attempt soon.

[viniciusdc]

Currently addressing an inconsistency with the admin kubeconfig and the exec command, while making sure that the appropriate python data object under tf_objects is correctly handled as well. The main issue, seems to be the current level of nesting associated with the credentials outputting logic, to properly handle the on/off variation of enabling RBAC we need to workaround uinsg a new child module for returning the appropriate credentials attributes later on used by the kubernetes provider, this is a bit tricky, since they change not only in naming but also in functionality.