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

1. 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.
2. 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.

Note

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.

1. Set CLUSTER_NAME, RESOURCE_GROUP and SUBSCRIPTION_ID variables.

   CLUSTER_NAME="myNexusK8sCluster"
   RESOURCE_GROUP="myResourceGroup"
   SUBSCRIPTION_ID=<set the correct subscription_id>
   

2. Query managed resource group with az and store in MANAGED_RESOURCE_GROUP

    az account set -s $SUBSCRIPTION_ID
    MANAGED_RESOURCE_GROUP=$(az networkcloud kubernetescluster show -n $CLUSTER_NAME -g $RESOURCE_GROUP --output tsv --query managedResourceGroupConfiguration.name)
   

3. 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 &
   

4. Use kubectl to send requests to the cluster:

   kubectl get pods -A
   

   You should now see a response from the cluster containing the list of all nodes.

Note

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.

1. 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.

2. Take note of the Microsoft Entra group object ID generated upon creation.

3. 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_ID with 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-users that assigns the view role to the members of the specified Microsoft Entra group.

4. Verify that the role binding was created successfully.

   kubectl get clusterrolebinding nexus-read-only-users
   

5. Now the users in the Microsoft Entra group have 'view' access to the cluster. They can access the cluster using az connectedk8s proxy to view the resources, but can't make any changes

Next steps

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.