Visualize Azure Active Directory Role-Based Access Control for Kubernetes

Acronyms:

• AAD - Azure Active Directory
• AKS - Azure Kubernetes Service
• RBAC - Role-based access control

Recently, I implemented AAD for AKS RBAC. The documentation doesn't do a great job of visualizing what the mappings look like, so here's a quick view of how you can think of it.

Let's briefly consider the permission scenario pictured above for some insights.

Group 1

Group 1 consists of 3 users. This group is bound by two different Kubernetes Role Bindings to two different roles. Perhaps these are developers who frequently work on two separate apps that are in different separate namespaces.

Group 2

Notice that user 2 appears here as well. Since he was placed in both AAD groups, he now has been bound to all of our roles, so he has all of the permissions that have been granted.

User 5

You might ask why he's not in group 1. If we put him in group 1, he would also have the permissions granted in role 1. We don't want that. He doesn't work on that part of the system. He's the one and only person who needs access to role 2, but not role 1.

Additional Notes

• Users can be placed into multiple AAD groups.
• AAD groups and users can be used by multiple role bindings.
• Roles can be used by multiple role bindings.
• Users and groups can be mapped to more than one role.
• It is very possible to lock yourself out of your own cluster. Azure Kubernetes Service allows you to define cluster admins from the portal, so you can always get back in.

I hope this helps you think about your RBAC mappings as you plan out your permissions strategy.

Happy Kuberneting!