Using the cloud shell, we have been acting as root, which allowed us to pretty much do anything and everything in the cluster. For production use cases, this root access is dangerous and not allowed in selected regulated environments. It is a generally-accepted best practice to use the principle of least privilege (PoLP) to log into any computer system, so as to avoid unintentional downtime through deleting key resources while thinking that you were operating on the local cluster (been there, done that). Anywhere between 22% and 29% (https://blog.storagecraft.com/data-loss-statistics-infographic/) of data loss is attributed to human error. You don't want to be part of that statistic (it is very painful).

Kubernetes developers realized this was a problem, and added RBAC along with the concept of service roles to control access to the cluster.

Service roles let you assign read-only and read/write access to Kubernetes resources. You can say person X has read-only access to the pods running in a namespace. The neat thing about AKS is that the person can be tied to Azure Active Directory (which in turn can be linked to your corporate Active Directory via an SSO solution).