Azure Policies in AKS

So, what can actually go wrong in an unmanaged cluster? More than you might think. A developer could accidentally (or deliberately) pull a container image from an untrusted registry. Or someone might be running a cryptominer in the background, especially if you’re using expensive GPU nodes. 

Sometimes applications are deployed to run as root, which poses a major security risk. Key configurations like resource requests and limits are often missing too, meaning one app could hog all resources and destabilize the entire cluster. Or everything is being dumped into the default namespace, which quickly becomes unmanageable. 

The result? Security incidents, instability, unexpected costs, and a cluster that’s hard to maintain. Not exactly ideal. 

To avoid such chaos, you can use Azure Policy for Kubernetes. It's a service within Azure that lets you define and establish certain rules, called policies, on your AKS clusters. Under the hood, it leverages well-known open-source technologies being Open Policy Agent (OPA) and Gatekeeper. 

The principle is simple: you define what’s not allowed on your cluster; or, just as importantly, what must be in place. Think ‘containers must not run as root’ or ‘resource requests are mandatory’. While many of Microsoft’s AKS-specific policy definitions are still in preview, the underlying tech is mature, and there’s already a lot you can enforce today. 

Azure Policy lets you take precise control. Here are a few practical examples of commonly used policies:  

The good news is that Azure Policy for Kubernetes brings with it little to no extra cost, aside from some compute for the agent pods running on your cluster. 

The real ‘cost’ lies elsewhere: in the time and expertise needed for implementation. Setting up, configuring and fine-tuning policies, adjusting existing apps where needed, and most of all, explaining to your teams why certain things are no longer allowed; those are serious efforts. 

Kubernetes is already complex, and policies add another layer. A developer whose deployment suddenly gets blocked, needs to understand why. Even more so with open-source tools, not everything will immediately meet your policy requirements. 

That can cause friction, and that’s why policies are often seen as ‘something for later’, particularly in smaller projects or when budgets are tight. A pity, really, because policies are a fundamental best practice. 

At Lume, we see policies as a vital step towards a mature, secure, and manageable AKS cluster. Even if they fall outside the initial scope of a fast-moving project, we generally recommend them. 

Especially for organizations and larger enterprises, policies are indispensable to stay in control of the environment. The time investment will pay off over time with fewer risks, more stability, and easier manageability. 

A default AKS cluster gives you lots of freedom, but without oversight, it quickly becomes the Wild West. Policies are the key to regaining control and transforming your cluster into a secure, consistent, and well-managed environment. Yes, it takes time and effort, but the benefits in security, stability, and governance are significant. Don’t wait until it’s too late; get your AKS policies in order.