Role-based access control in Azure Operator Nexus Kubernetes clusters
This article provides a comprehensive guide on how to manage access to Nexus Kubernetes clusters using Microsoft Entra ID. Specifically, we're focusing on role-based access control, which allows you to grant permissions to users based on their roles or responsibilities within your organization.
Before you begin
- To begin, create a Microsoft Entra group for your cluster administrators and assign members to it. Microsoft Entra ID allows access to be granted to the group as a whole, rather than managing permissions for each user individually.
- Use the group ID you created as the value for 'adminGroupObjectIds' when creating the Nexus Kubernetes cluster to ensure that the members of the group get permissions to manage the cluster. Refer to the QuickStart guide for instructions on how to create and access the Nexus Kubernetes cluster.
Administrator access to the cluster
Nexus creates a Kubernetes cluster role binding with the default Kubernetes role
cluster-admin and the Microsoft Entra groups you specified as
adminGroupObjectIds. The cluster administrators have full access to the cluster and can perform all operations on the cluster. The cluster administrators can also grant access to other users by assigning them to the appropriate Microsoft Entra group.
When you create a Nexus Kubernetes cluster, Nexus automatically creates a managed resource group dedicated to storing the cluster resources, within this group, the Arc connected cluster resource is established.
To access your cluster, you need to set up the cluster connect
kubeconfig. After logging into Azure CLI with the relevant Microsoft Entra entity, you can obtain the
kubeconfig necessary to communicate with the cluster from anywhere, even outside the firewall that surrounds it.
CLUSTER_NAME="myNexusK8sCluster" RESOURCE_GROUP="myResourceGroup" SUBSCRIPTION_ID=<set the correct subscription_id>
Query managed resource group with
azand store in
az account set -s $SUBSCRIPTION_ID MANAGED_RESOURCE_GROUP=$(az networkcloud kubernetescluster show -n $CLUSTER_NAME -g $RESOURCE_GROUP --output tsv --query managedResourceGroupConfiguration.name)
The following command starts a connectedk8s proxy that allows you to connect to the Kubernetes API server for the specified Nexus Kubernetes cluster.
az connectedk8s proxy -n $CLUSTER_NAME -g $MANAGED_RESOURCE_GROUP &
kubectlto send requests to the cluster:
kubectl get pods -A
You should now see a response from the cluster containing the list of all nodes.
If you see the error message "Failed to post access token to client proxyFailed to connect to MSI", you may need to perform an
az login to re-authenticate with Azure.
Role-based access control
As an administrator, you can provide role-based access control to the cluster by creating a role binding with Microsoft Entra group object ID. For users who only need 'view' permissions, you can accomplish the task by adding them to a Microsoft Entra group that's tied to the 'view' role.
Create a Microsoft Entra group for users who need 'view' access, referring to the default Kubernetes role called
view. This role is just an example, and if necessary, you can create custom roles and use them instead. For more information on user-facing roles in Kubernetes, you can refer to the official documentation at Kubernetes roll-based access roles.
Take note of the Microsoft Entra group object ID generated upon creation.
Use the kubectl command to create a clusterrolebinding with the 'view' role and associate it with the Microsoft Entra group. Replace
AZURE_AD_GROUP_OBJECT_IDwith the object ID of your Microsoft Entra group.
kubectl create clusterrolebinding nexus-read-only-users --clusterrole view --group=AZURE_AD_GROUP_OBJECT_ID
This command creates a cluster role binding named
nexus-read-only-usersthat assigns the
viewrole to the members of the specified Microsoft Entra group.
Verify that the role binding was created successfully.
kubectl get clusterrolebinding nexus-read-only-users
Now the users in the Microsoft Entra group have 'view' access to the cluster. They can access the cluster using
az connectedk8s proxyto view the resources, but can't make any changes
You can further fine-tune access control by creating custom roles with specific permissions. The creation of these roles involves Kubernetes native RoleBinding or ClusterRoleBinding resources. You can check the official Kubernetes documentation for detailed guidance on creating more custom roles and role bindings as per your requirements.