Operation and Maintenance of AKS Applications

In production systems, you need to allow different personnel access to certain resources; this is known as role-based access control (RBAC). This chapter will take you through how you can turn on RBAC on AKS and practice assigning different roles with different rights. Users would be able to verify that their access is denied when trying to modify resources that they do not have access to. The benefits of establishing RBAC are that it acts not only as a guardrail against the accidental deletion of critical resources but also an important security feature to limit full access to the cluster to roles that really need it.

The following topics will be covered in this chapter:

• Service roles in Kubernetes
• Attaching service roles to Azure AD users
• Verifying RBAC

Technical requirements

You will need a modern web browser, such as Chrome, Firefox, or Edge.

Service roles in Kubernetes

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

Attaching service roles to AAD users

We will be creating users in our directory and assigning roles to them.

Creating users in your Active Directory

Select Azure Active Directory->Users and select New user. As shown in the following screenshot:

Do not select New guest user. Guest users cannot be assigned roles.

The username has to be in the domain that you are the admin of. In this case, an Outlook account was used and hence the domain name is handsonaksoutlook.onmicrosoft.com. Write down the password.

Creating a read-only group and adding the user to it

To demonstrate...

Verifying RBAC

Let's give it a spin by creating the RBAC roles on Kubernetes and checking whether it actually works.

Creating the read-only user role

On the cloud shell, connect to your cluster.

Note that you have to specify --admin so that you can work on your cluster:

az aks get-credentials --resource-group handsonaks-rbac --name handsonaks-rbac --admin

Creating the cluster-wide, read-only role

Create the following file and save it as cluster-read-only-role.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
  name: read-only
rules...

Summary

In this chapter, we learned how to secure your AKS cluster with role-based security by leveraging Azure Active Directory as the authentication provider. We created a service role that lets you assign read-only or read/write access to Kubernetes resources, and we looked at some advanced features. First, we showed you how to create the AAD server application. Then we created the client application. After that, we showed you how to get the AAD tenant ID and deployed the cluster. Once we had the RBAC-enabled solution deployed, we tested the read-only feature by creating users in the Active Directory. We then created a read-only group and added the user to it. We finished the chapter by creating the read-only user role and binding the role to the AAD group of the user.

In the next chapter, you will learn how to authorize Kubernetes cluster applications to connect to other...