Introduction

Kubernetes Role-Based Access Control (RBAC) provides a comprehensive mechanism for securing Kubernetes clusters by defining users’ or groups’ actions on different resources. Integrating RBAC with Azure Active Directory (Azure AD) enhances security by leveraging Azure AD’s robust identity management features. This integration simplifies user management by centralizing it within Azure AD and improves security through features like multi-factor authentication and conditional access policies. This document provides an overview of Kubernetes RBAC and its integration with Azure AD, as well as a step-by-step guide on setting up this integration, highlighting the advantages and limitations of using Azure AD with Kubernetes RBAC.

Overview of Kubernetes RBAC

• A security mechanism that regulates access to resources within a Kubernetes cluster. It assigns roles (sets of permissions) to users or groups.
• RBAC enhances cluster security by ensuring only authorized personnel can interact with Kubernetes resources based on their defined roles and associated permissions.
• Roles define what actions are allowed on specific resources, while Role & RoleBindings and ClusterRole & ClusterRoleBindings connect roles to users or groups. RBAC ensures proper authorization, helps maintain the principle of least privilege, and enhances overall cluster security.

Kubernetes allows you to configure custom roles or use default user-facing roles, including, but not limited to:

• Cluster-admin: This “superuser” can perform any action on any resource in a cluster. You can use this in a ClusterRoleBinding to grant complete control over every resource in the cluster (and in all namespaces) or in a RoleBinding to grant complete control over every resource in the respective namespace.
• Admin: This role permits unlimited read/write access to resources within a namespace. It can also create roles and role bindings within a particular namespace. However, it does not permit write access to the namespace itself.
• Edit: This role grants read/write access within a given Kubernetes namespace. It cannot view or modify roles or role bindings.
• View: This role allows read-only access within a given namespace. It does not allow viewing or modifying of roles or role bindings.

Limitations of Native K8S Local Accounts

• Authentication using local accounts for both user and admin access / Authorization using Kubernetes RBAC (default)
• As Kubernetes lacks an integrated identity management system, administrators must manually generate a certificate for each user, signed by the cluster’s certificate authority, to create additional users.

Integrating User Identity Management in Kubernetes

• Kubernetes lacks a native mechanism for defining and managing users. Instead, administrators can integrate their preferred organization identity service provider to access the cluster. This integration prevents the need to duplicate user management efforts.
• With Azure Kubernetes Service, you can seamlessly integrate with Azure AD, a robust enterprise-grade identity management solution that is the authoritative source for account management and security.

Advantages of using Kubernetes RBAC with Azure AD

• Integrating Kubernetes RBAC with Azure AD allows organizations to maintain a centralized user identity and access management system. Azure AD serves as the single source of truth for user accounts, simplifying user management and reducing the risk of inconsistencies.
• Azure AD provides robust security features, including multi-factor authentication (MFA) and conditional access policies. By leveraging these capabilities, Kubernetes clusters benefit from enhanced security and reduced risk of unauthorized access.
• Kubernetes RBAC combined with Azure AD enables fine-grained access control. Organizations can assign specific roles and permissions to users based on their Azure AD group membership or attributes, ensuring users have access only to the resources they need.
• Azure Kubernetes Service (AKS) seamlessly integrates with Azure AD, simplifying the setup and configuration process. Administrators can leverage Azure AD features and policies without complex customizations.

Disadvantages of using Kubernetes RBAC with Azure AD:

• Setting up the integration between Kubernetes RBAC and Azure AD can be initially complex and may require in-depth knowledge of both systems. Configuring the correct mappings between Azure AD groups and Kubernetes RBAC roles can be challenging.
• Organizations are heavily reliant on Azure AD, which may face challenges if it experiences downtime or service interruptions. This dependency could impact managing user access to Kubernetes resources during such periods.
• IT teams unfamiliar with Azure AD may need help understanding its features and functionalities. This may require additional training and support to manage and utilize Azure AD within the Kubernetes environment effectively.
• While Azure AD provides extensive identity and access management capabilities, it may come with additional costs, especially for organizations with large user bases. The cost implications should be considered when opting for this integration.

Overall, the advantages of using Kubernetes RBAC with Azure AD outweigh the disadvantages for many organizations, especially those already invested in the Microsoft Azure ecosystem.

It offers a secure and streamlined approach to managing user access within Kubernetes clusters, leveraging Azure AD’s robust identity management capabilities.

However, each organization should carefully assess its requirements and weigh the pros and cons before adopting this integration.

How to set up the K8S RBAC with Azure AD?

• Create 2 AAD Groups for admin & dev groups using the following commands or the Azure Microsoft Entra ID

az ad group create --display-name k8s-admin --mail-nickname k8s-admin
az ad group create --display-name k8s-dev --mail-nickname k8s-dev

 

 

 

• Create users and assign them to the respective groups.

 

 

 

 

• Assign roles to provide owner access to the subscription for the groups created above.

 

 

 

 

• Create AKS Cluster in Azure Portal with K8S RBAC enabled

 

 

• Keep two terminals or tabs for admin login and dev login, respectively
  • On Terminal 1 (Admin), execute the az login command to log in to Azure. Ensure to log in with the admin user credentials when the browser opens for portal login
  • On Terminal 2 (dev), execute the az login command to log into Azure with the dev user credentials.

az login
az ad signed-in-user show

Admin Login

1. 

Dev Login

 

• Once logged into Azure on both terminals, execute the following commands to connect to the AKS Cluster.

az account set --subscription 

az aks get-credentials --resource-group aks-rbac-poc-rg --name aks-rbac-poc-cluster --overwrite-existing

kubelogin convert-kubeconfig -l azurecli

kubectl get ns 

• On the Admin Terminal,
  • Create a namespace called dev-space

kubectl create ns dev

kubectl get ns

• • Create a sample deployment and a service in the dev-space namespace.

kubectl create deployment my-deployment --image=nginx --namespace=dev

kubectl expose deployment my-deployment --type=LoadBalancer --port=80 --target-port=8080 
--namespace=dev 

• • Create the Role & RoleBinding with the following rules & subjects, respectively. Added the Dev AAD Group ID as the subject in RoleBinding

kubectl create role dev-user --verb=list,get --resource=pods,deployments --namespace=dev

kubectl create rolebinding dev-user-binding --role=dev-user --group=9fc8128a-cf3f-49b2-b6aa-
e745d355fd65 --namespace=dev-space 

• To test the RBAC,
  • On the Dev Terminal, let’s try a few commands and observe the result

kubectl get pod -n dev

kubectl get ns

kubectl get deployment

kubectl get deployment -n dev 

It’s impossible, as per the RoleBinding, the dev group has been provided with only the “pod” and “deployment” read permissions for the namespace “dev”.

• • On the Admin Terminal, and it will be successful. The admin group has ClusterRoleBinding with all the permissions enabled.

kubectl get pod -n dev

kubectl delete pod my-deployment-5f8fc99b79-5jclr -n dev

Important Considerations

If a user is in both the admin and dev user groups or has both RoleBinding and ClusterRoleBinding, the permissions mentioned in both will be added for that user.

An RBAC Role or ClusterRole contains rules that represent a set of permissions. Permissions are purely additive (there are no “deny” rules).

Ref: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole

Conclusion

Integrating Kubernetes RBAC with Azure AD offers significant benefits, including streamlined user management, enhanced security, and simplified configuration through Azure Kubernetes Service (AKS). Organizations can ensure consistent and secure access control across their Kubernetes environments by centralizing user identity and access management.

While the initial setup may be complex and requires a good understanding of both systems, the long-term advantages of improved security and simplified user management often outweigh these challenges. Each organization should carefully evaluate its requirements and the potential benefits and drawbacks before implementing this integration to ensure it aligns with its operational needs and security objectives.

Reference

• https://learn.microsoft.com/en-us/azure/aks/azure-ad-rbac?tabs=portal
• https://learn.microsoft.com/en-us/azure/aks/hybrid/kubernetes-rbac-azure-ad