Azure AKS : Azure RBAC for Kubernetes Authorization

Introduction

Azure AKS (Azure Kubernetes Service) is a fully managed service provided by Microsoft Azure for deploying and scaling containerized applications in the cloud using Kubernetes. This article covers the approach that allows for unified management and access control to AKS and Kubernetes resources. Traditionally access to Kubernetes resources can be provided to the users using Kubernetes RBAC policies but we are going to look at the benefits of using Azure RBAC, hoping to not complicate the Security Landscape for our future deployments.

We will not be creating any RBAC policies/roles inside the Kubernetes cluster, roles would only be created on the azure platform and mapped to namespaces inside the managed cluster. This frees us from having to create and manage separate users inside Kubernetes.

Limitations

There are a couple of caveats we should look at, even before proceeding.

• RBAC for Kubernetes resources can be managed using Azure or through native Kubernetes RBAC policies

• Azure AD principals will be validated exclusively by Azure RBAC while regular Kubernetes users will be exclusively validated by Kubernetes RBAC
• It is required that we set up Managed Azure AD Integration for our Managed Cluster
• Use kubectl v1.18.3+
• New Role assignments take upto 5 mins to fully propagate and update.
• Azure AD and the AKS cluster should reside in the same tenant.
• The only way to cover CRDs or Custom Role Definitions is to provide Microsoft.ContainerService/managedClusters/*/read . AKS is working to provide more granular permissions for CRDs.

Integrating Azure RBAC into an AKS cluster

We will enable azure RBAC for an existing cluster(it is not enabled by default) and then assign the default roles provided by AKS to users enabling them to execute commands using kubectl inside the cluster.

The below command enables the Azure RBAC

az aks update -g myResourceGroup -n myAKSCluster --enable-azure-rbac

Default roles for users to access the cluster

Here we will not create any roles since, 4 built-in default roles are provided by Azure

Azure Kubernetes Service RBAC Reader

• Allows read-only access in a namespace.
• Doesn't allow viewing roles or role bindings. This role doesn't allow viewing Secrets, since reading the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount in the namespace

Azure Kubernetes Service RBAC Writer

• Allows read/write access to most objects in a namespace.
• This role doesn't allow viewing or modifying roles or role bindings.
• This role allows accessing Secrets and running Pods as any ServiceAccount in the namespace, so it can be used to gain the API access levels of any ServiceAccount in the namespace.

Azure Kubernetes Service RBAC Admin

• Allows admin access, intended to be granted within a namespace
• Allows reading/write access to most resources in a namespace (or cluster scope), including the ability to create roles and role bindings within the namespace.
• This role doesn't allow write access to the resource quota or to the namespace itself.

Azure Kubernetes Service RBAC Cluster Admin

• Allows super-user access to perform any action on any resource.
• It gives full control over every resource in the cluster and in all namespaces.
  

Role Assignments

Roles are usually created by assigning the default roles to users for a particular namespace existing within the Kubernetes cluster. It is also possible to create custom role definitions as well.

• Get your AKS Cluster Resource ID using the below command in Azure CLI

AKS_ID=$(az aks show -g MyResourceGroup -n MyManagedCluster --query id -o tsv)

• Role assignments scoped to a specific **namespace** within the cluster are done using the below command

az role assignment create

--role "Azure Kubernetes Service RBAC Reader"

--assignee AAD-ENTITY-ID;

--scope $AKS\_ID/namespaces/namespace-name;

• If you wanted to assign the role to the entire AKS Cluster we would need to change the scope to just $AKS_ID

az role assignment create
--role "Azure Kubernetes Service RBAC Reader"
--assignee AAD-ENTITY-ID;
--scope $AKS_ID

where AAD-ENTITY-ID could be a username (e.g. frog@example.com) or even the ClientID of a service principal.

Checking the access provided

Looking at the previous example, if you observe we provided the access to frog@example.com, assuming that frog wants to check the number of nodes running in the default namespace inside MyManagedCluster, he would first have to get the cluster's kubeconfig using the below command.

az aks get-credentials -g MyResourceGroup -n MyManagedCluster

Now, frog can run commands using kubectl only for resources that he has access to.

Conclusion

We have discussed the user/client administration strategy in this articles in the hopes that it would be helpful for the admins to manage the administration as well as the governance for their clusters. Feel free to drop improvements or any suggestions