If you are looking for a step-by-step guide on how to enable authentication for your Azure Kubernetes Service (AKS) cluster, you may have encountered some challenges. The documentation on this topic is scarce and often outdated or incomplete. Moreover, you may have specific requirements for your use case that are not covered by the existing resources. That is why I have created this comprehensive guide using the latest Azure cloud resources. Part 2 is here Part 2
In this guide, you will learn how to set up an AKS cluster and provide authentication to that cluster using NGINX and the OAuth2 proxy. This guide is intended for educational purposes only and does not guarantee proper authentication as certified by NIST. It is also not a complete solution for securing your AKS cluster, which involves more than just authentication. Therefore, this guide should be used as a learning tool to help you understand how authentication works and how to implement it using Azure.
By following this guide, you will be able to set up an AKS cluster with authentication using NGINX, OAuth2 Proxy, and Microsoft Entra ID. You will not need a domain name as we will use a fully qualified domain name (FQDN). However, you can also use a domain name if you prefer. Additionally, we will use Let’s Encrypt for TLS certificates so that our application will use HTTPS.
Additionally, I have broken this guide into several parts. This is the first part where you will be guided through the creation of your AKS cluster and the initial NGINX configuration. I will provide the remaining parts in future posts.
To learn how to use NGINX with Oauth2 Proxy, I conducted thorough online research and consulted various tutorials, guides, and other sources of information. The following list contains some of the most helpful references that I used to create this guide. You may find them useful as well if you need more details or clarification on any aspect of this topic.
Getting Started
Before you begin, you will need to meet the following prerequisites:
- Azure CLI or Azure PowerShell
- An Azure subscription
- An Azure Resource Group
Create an Azure Container Registry (ACR)
To create an Azure container registry, you can follow the steps outlined in the official documentation here Create a new ACR. An Azure container registry is a managed Docker registry service that allows you to store and manage your private Docker container images and related artifacts. For now I’ll set up an ACR using PowerShell:
First, you’ll need to login:
az login –use-device-code
Then define a name for your ACR resource:
$MYACR=your_acr_name
Then create your ACR resource:
New-AzContainerRegistry -Name $MYACR -ResourceGroupName YOUR_RESOURCE_GROUP_NAME -Sku Basic
You may be prompted for a location, enter your location, and proceed.
Create an AKS cluster and integrate with ACR
Now create a new AKS cluster and integrate with the existing ACR you just created by running the following command.
New-AzAksCluster -Name YOUR_AKS_CLUSTER_NAME -ResourceGroupName myResourceGroup -GenerateSshKey -AcrNameToAttach $MYACR
The command above will configure the appropriate AcrPull role for the managed identity and allows you to authorize an existing ACR in your subscription. A managed identity from Microsoft Entra ID allows your app to easily access other Microsoft Entra protected resources.
Validate the Deployment
We will verify the deployment using the Kubernetes command line client. Ensure that you have this tool installed by running the following command.
Install-Module Az.Aks
Configure the kubectl client to connect to your Kubernetes cluster. The following command downloads credentials and configures the Kubernetes CLU to use them.
Import-AzAksCredential -ResourceGroupName myResourceGroup –Name myAKSCluster
Verify the connection to your cluster by running the following command.
kubectl get nodes
You should see some output with the name of the nodes on your cluster.
NGINX Ingress controller configuration
Now that we have our AKS cluster up and running with an attached ACR we can configure our ingress controller NGINX. The NGINX ingress controller provides a reverse proxy for configurable traffic routing and TLS termination. We will utilize NGINX to fence off our AKS cluster providing a public IP address accessible through the load balancer which we can then assign a FQDN for accessing our applications. Additionally, we can configure NGINX to integrate with Microsoft Entra ID for authenticating users via an OAuth2 Proxy. Those details will be shared in a later post. You can follow the basic configuration for an ingress controller on the official documentation here Create an unmanaged ingress controller.
Before configuration begins, make sure you have Helm installed. Then run the following commands.
$Namespace = 'ingress-basic'
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress-nginx ingress-nginx/ingress-nginx `
--create-namespace `
--namespace $Namespace `
--set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz `
--set controller.service.externalTrafficPolicy=Local
Check the load balancer
Now that you have configured and installed the NGINX ingress controller you can check the load balancer. Run the following command.
kubectl get services --namespace ingress-basic -o wide -w ingress-nginx-controller
You should see some output. When Kubernetes creates the load balancer service a public IP address is assigned. You can view the IP address under the column EXTERNAL-IP. Make note of this IP address. If you browse to that IP address you should get a 404 Not Found.
This wraps up the first part of this series. In the next part I will go over deploying two applications and creating the ingress routes to route to the applications. Then we will move on to setting up cert manager and getting things ready for our OAuth2 Proxy provider.
