Welcome to the Azure AKS Kubernetes deployment security Workshop.
We won’t spend too much time on the presentation of AKS, the service that has been very popular in recent months.
In brief, AKS is Microsoft’s new managed container orchestration service. It is gradually replacing Azure Container service and focuses only on the Cloud Native Computing foundation (CNCF) Kubernetes orchestration engine.
In the last lab: Create a Kubernetes cluster with Azure AKS using Terraform, we have discussed the Azure Kubernetes Service (AKS) basics, the Infrastructure as Code (IaC) mechanism with a focus on Hashicorp Terraform and how to deploy a Kubernetes cluster with AKS using Terraform.
With this lab, you’ll go through tasks that will help you master the basic and more advanced topics required to secure Azure AKS Kubernetes cluster at the deployment level based on the following mechanisms and technologies:
- ✅Azure AD (AAD)
- ✅AKS with Role-Based Access Control (RBAC)
- ✅Container Network Interface (CNI)
- ✅Azure Network policy
- ✅Azure Key Vault
This article is part of a series:
- Secure AKS at the deployment: part 1
- Secure AKS at the deployment: part 2
- Secure AKS at the deployment: part 3
Assumptions and Prerequisites
- You have basic knowledge of Azure
- Have basic knowledge of Kubernetes
- You have Terraform installed in your local machine
- You have basic experience with Terraform
- Azure subscription: Sign up for an Azure account, if you don’t own one already. You will receive USD200 in free credits.
Implement RBAC to secure AKS at the deployment
In this part, we will continue our exploration of the use of Azure Active Directory (AAD) . We will detail the deployment steps with Terraform and Azure provider and Kubernetes in order to implement RBAC authentication mechanism to with Azure AKS Kubernetes.
This implementation is based on the last Infra as Code lab: Create a Kubernetes cluster with Azure AKS using Terraform
1- Deployment of an AKS cluster integrated with Azure AD
Now that the prerequisites are done at the Azure AD level, we can deploy the AKS cluster using a Terraform config. For the AKS resource, we use azurerm_kubernetes_cluster.
The first step is to obtain the source code from Github. Likewise, you can simply update your own Terraform implementation as I will explain in the following steps.
This will clone the sample repository and make it the current directory:
|–⫸ git clone https://github.com/AymenSegni/azure-aks-k8s-tf.git
|–⫸ cd azure-aks-k8s-tf
Next, we need to update (use your preferred editor) the aks-cluster main resources to integrate AAD in the deployment.
|–⫸ vi src/modules/aks-cluster/main.tf
Inside, update the Terraform code as shown below, then save and close.
The most important block for AAD integration is in the
role_based_access_control block. Obviously, RBAC must be activated, so the enabled parameter must have
the value true. Second, we must reference the AAD applications prepared in the previous sections, with the secret for the application server, the app id for the two applications as well as the tenant Azure Active Directory.
Hard coding this information is not a good practice, so we use Azure Key Vault for the value of these variables when calling the module, as shown below.
To properly secure access to the Key Vault, it’s of course necessary to define an access policy which gives Terraform only read access to the associated application for deployment.
The next stage, so is to update the root cluster deployment when calling the AAD integarted aks-cluster Terraform module
|–⫸ vi src/deployment/main.tf
Inside, update the Terraform code as shown below, then save and close.
As you will notice, it is also necessary to update the variable .tf files in the aks-cluster module and the main Terraform deployment configuration.
After making changes to your code, running the
apply commands again will let Terraform use its knowledge of the deployed resources
(.tfstate) to calculate what changes need to be made, whether building or destroying.
Finally, get the cluster admin credentials using the
az aks get-credentials command. In one of the following steps, you get the regular user cluster credentials to see the Azure AD authentication flow in action.
|–⫸ az aks get-credentials –resource-group myResourceGroup –name $aksname –admin
The AKS cluster deployment with the AAD integration can be done through Azure CLI as shown below:
|–⫸ tenantId=$(az account show –query tenantId -o tsv)
|–⫸ az aks create –resource-group myResourceGroup –name $aksname –node-count 1 –generate-ssh-keys –aad-server-app-id $serverApplicationId –aad-server-app-secret $serverApplicationSecret –aad-client-app-id $clientApplicationId –aad-tenant-id $tenantId
2- Create RBAC
The next step is to associate the AAD identities on the Kubernetes cluster, using the Kubernetes Roles, ClusterRoles, clusterRoleBinding or RoleBinding objects. In our case, we are using existing roles:
- The cluster-role cluster-admin, which as its name suggests gives extended rights to the whole cluster,
- The cluster-role admin which gives extended rights but which associates with a namespace.
Roles define the permissions to grant, and bindings apply them to the desired users. These assignments can be applied to a given namespace, or across the entire cluster. For more information, see Using RBAC authorization.
1- Get the user principal name (UPN) for the user currently logged in using the
az ad signed-in-user show command. This user account is enabled for Azure AD integration in the next step.
2- Create a YAML manifest named
basic-azure-ad-binding.yaml and paste the following contents. On the last line, replace
userPrincipalName_or_objectId with the UPN or object ID output from the previous command:
3- Create the ClusterRoleBinding using the kubectl apply command and specify the filename of your YAML manifest:
|–⫸ kubectl apply -f basic-azure-ad-binding.yaml
3- Authentication test
Now let’s test the integration of Azure AD authentication for the AKS cluster. The first step is to retrieve the identifiers. To do this, we use the
az aks get-credentials command, after performing authentication on az cli. This implies, as it stands, that the person has access to the subscription in which the AKS cluster is located. However, once the config file is recovered, only the kubectl client is required.
After executing this first command, first with an account linked to the cluster-role cluster-admin, we then execute the command
kubectl get pods, which requires rights at the cluster level, which is the case with the account present:
|–⫸ az aks get-credentials –resource-group myResourceGroup –name $aksname –overwrite-existing
|–⫸ kubectl get pods –all-namespaces
You receive a sign in prompt to authenticate using Azure AD credentials using a web browser. After you’ve successfully authenticated, the
kubectl command displays the pods in the AKS cluster, as shown in the following example output:
In this part, we deployed an AKS cluster integrated with AAD to implement an RBAC, and then we successfully tested authentication with AAD users, not necessarily having direct rights to the resource in Azure. In a next part, we will implement Network Policies in order to secure the Azure AKS Kubernetes cluster at the deployment level.
In a next chapter, we will implement security at the AKS cluster level using Network Policies.
2 thoughts on “Secure AKS at the deployment – part 2 –”