1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Configuring Azure VM and Container Security

Configuring Authentication

Start course

This course focuses on implementing security controls, maintaining the security posture of an Azure environment, and protecting data, applications, and networks, showing you how to configure security for your containers and virtual machines.

The content of this course is ideally suited to those looking to become certified Azure security engineers.

For any feedback, queries, or suggestions relating to this course, please contact us at support@cloudacademy.com.

Learning Objectives

  • Understand how to configure VM security including VM endpoints and system updates
  • Configure baselines
  • Understand key Azure networking components
  • Configure AKS security
  • Obtain a basic understanding of Azure Container Registry and how to create registries in Azure
  • Manage vulnerabilities in Azure

Intended Audience

This course is intended for people who want to become Microsoft certified Azure security engineers, or those who are tasked with implementing security controls, maintaining the security posture of an Azure environment, or protecting data, applications, and networks.


To get the most from this course, you should have a moderate understanding of Microsoft Azure and of basic security principles.


Hi there, welcome to configuring authentication. In this lecture, we're going to take a look at how to create and use service principals for AKS clusters.

So before an AKS cluster can interact with Azure APIs, it needs an Azure AD service principal. This is required to dynamically create and manage other Azure resources, like Azure load balancer or container registry. 

Over the next few minutes here, I'm going to explain how to create a service principal for an AKS cluster.

Before we dive in, I need to point out that in order to create an Azure AD service principal, you need permissions to register an application with the Azure AD tenant. You also need permissions to assign the app to a role in the subscription.

To create a service principle for an AKS cluster using Azure CLI, you'll need to use Azure CLI version 2.0.59 or later installed and configured.

When you create an AKS cluster, be it in the Azure portal or by using the az aks create command in Azure CLI, Azure can automatically create a service principal for you.

Using the Azure CLI command that you see on your screen (shown below) does not specify a service principal, so what happens in this case is Azure CLI automatically creates a service principal for the cluster.

az aks create --name MyCoolAKSCluster --resource-group myRG

Now, if you want to manually create a service principal using the Azure CLI, you can use this next command that you see on your screen:

az ad sp create-for-rbac --skip-assignment --name myAKSClusterSP

In this example, we're using the az ad sp create-for-rbac command. The --skip-assignment parameter in this example command prevents any additional default assignments from being assigned.

After running the command you see here, what you need to do is take a look at your output, which should look something like what you see on your screen, and you'll need to make a note of the appID and password because you'll use these when you create your AKS cluster. Once you've created your service principal, you can use it when you create the AKS cluster.

  "appId": "559513bd-0c19-4c1a-87cd-851a26afd5fc",
  "displayName": "myAKSClusterSP",
  "name": "http://myAKSClusterSP",
  "password": "e765722a-5eee-40e8-a466-dc87d980f315",
  "tenant": "72f985bf-86f1-41af-92ab-2d7ce011db48"

To specify this existing service principal while you create the AKS cluster, you can use the az aks create command, along with the --service-principal and --client-secret parameters. Using these parameters allows you to specify the appID and password that you noted.

az aks create --resource-group myResourceGroup --name myCoolAKSCluster --service-principal <appId> --client-secret <password>

Now, if you're doing things the easier way and deploying your AKS cluster via the Azure portal, what you can do is, once you get to the Authentication page of the Create Kubernetes cluster dialog, you can choose the option to Use Existing when prompted to Configure service principal. What you would do in this case is provide your appID in the Service principal client ID field and your password in the Service principal client secret field.

Before we wrap up this lecture, I do want to point out a couple things to keep in mind when using AKS and Azure AD service principals.

First and foremost, while the service principal for Kubernetes is a part of the cluster configuration, it should not be used to deploy the cluster. Secondly, by default, service principal credentials are only valid for one year. That being the case, you'll need to either update or rotate the service principal credentials on a regular basis.

Speaking of service principals, every service principal is associated with an Azure AD application. In the case of a Kubernetes cluster, the service principal for it can be associated with any valid Azure AD application name. However, the application URL doesn't have to be a real endpoint. This sometimes trips people up.

I should also point out that the service principal credentials are stored in a file called /etc/kubernetes/azure.json on the agent node VMs within the Kubernetes cluster.

Lastly, even if you delete an AKS cluster that was created via the az aks create command, the service principal that was automatically created is not deleted. This is another point that sometimes trips people up.


Introduction - Configuring Endpoint Security within VMs - Configuring and Monitoring Antimalmare for VMs - Configuring Virtual Machine Security - Hardening Virtual Machines - Configuring System Updates for Virtual Machines - Starting a Runbook from the Azure Portal - Configuring Baselines - Azure Networking - Container Isolation - AKS Security - Azure Container Registry - Creating a Container Registry - Implementing Vulnerability Management - Conclusion

About the Author
Thomas Mitchell
Learning Paths

Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.

In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.

In his spare time, Tom enjoys camping, fishing, and playing poker.