To harden an AKS cluster, put API server access behind Microsoft Entra ID and Kubernetes RBAC, restrict the API server's network exposure, block pod access to the instance metadata endpoint, keep nodes and Kubernetes versions current, run pods without root or privilege, and use separate clusters for hostile tenants. Microsoft's docs set out each of these.
Who is responsible for what?
AKS runs the Kubernetes control plane for you. Microsoft's concepts page says the primary components are part of the managed service, with a single-tenanted control plane for each cluster. You own what runs on it: identities, network paths, workloads and node pool patching choices.
The docs also describe two cluster modes. AKS Automatic starts from a hardened baseline with more controls preconfigured, including Azure RBAC for Kubernetes authorization, API server virtual network integration, workload identity, deployment safeguards and baseline Pod Security Standards in enforce mode. AKS Standard gives more configuration control and more operator responsibility. Pick the mode knowing which controls you must turn on yourself.
How do you secure the API server?
Microsoft calls securing access to the Kubernetes API server one of the most important steps. Integrate Kubernetes RBAC with Microsoft Entra ID so you use existing users and groups, grant roles at the narrowest scope such as a single namespace, and get an audit trail.
On the network side, by default the API server has a public IP address and fully qualified domain name. You can limit it with authorized IP ranges, or create a private cluster so access stays inside your virtual network. For deployment pipelines, configure network access and authorization separately, since reaching the API server does not grant permissions. The docs advise workload identity federation with a dedicated identity instead of stored long-lived credentials, and avoiding cluster-admin credentials. They also note that Azure DevOps Microsoft-hosted agents are not supported with private AKS clusters, so plan a self-hosted agent or a managed pool inside the network.
What about the metadata endpoint?
The best-practices page recommends a network policy in all user namespaces that blocks pod egress to the instance metadata endpoint, 169.254.169.254. A pod that can reach it may retrieve credentials meant for the node. Network policy needs a network policy engine to be enabled when the cluster is created, so check your cluster's network model supports it.
How do you keep pods contained?
Limit container actions to the minimum. The docs say to avoid applications that need root or privilege escalation, and recommend the Linux features AppArmor and seccomp for finer control. They also describe user namespaces as improving host isolation and limiting lateral movement after a container breakout.
Kubernetes secrets deserve care. The docs explain secrets are delivered to nodes only when a pod needing them is scheduled, kept in tmpfs, and stored in etcd. The raw manifests carry base64 data, so never commit them to source control. AKS supports encrypting secrets in etcd with customer-managed keys.
How do you keep the cluster patched?
The best-practices page explains that Linux nodes get security patches each evening through the distribution's update channel, but nodes are not rebooted automatically when a patch needs it. That leaves nodes patched on disk and still running old code until a reboot. Plan reboot handling. Also note that the nightly updates do not change the base image, so a node added later starts from the original image and catches up. Use node image upgrades to refresh the image itself.
AKS supports three minor Kubernetes versions, and the oldest is retired when a new minor appears. Put the support window in your calendar and test upgrades in a non-production cluster first.
One dated item in the concepts page: Azure Linux 2.0 stopped receiving security updates on 30 November 2025, and from 31 October 2026 its node images are removed and you cannot scale those node pools. If any pool still runs it, migrate it now.
When is one cluster not enough?
The docs say Kubernetes environments are not safe for hostile multitenant use. For hostile tenants, use physically isolated clusters. Namespaces and RBAC separate teams who trust each other, not adversaries.
What to do
- Integrate Entra ID and RBAC, with namespace-scoped roles and no standing cluster-admin.
- Restrict the API server with authorized ranges or a private cluster, and use workload identity federation for pipelines.
- Apply a network policy that blocks pod egress to the metadata endpoint in every user namespace.
- Enforce non-root, no privilege escalation, AppArmor and seccomp profiles.
- Encrypt secrets in etcd and keep secret manifests out of Git.
- Automate node image upgrades, reboot handling and Kubernetes version upgrades.
- Scan the images and manifests you deploy. The free scan at gold.safeguard.sh/scan checks up to 100 dependencies.
Quick check
Does AKS reboot nodes after kernel patches?
Not automatically. Microsoft says nodes get nightly security patches but are not rebooted by default, so you must plan reboots.
Are namespaces enough to isolate hostile tenants?
No. Microsoft says to use physically isolated clusters for hostile multitenant workloads.
Sources
- Microsoft Learn: Best practices for cluster security in AKS
- Microsoft Learn: Security concepts for AKS
Last reviewed: 18 October 2026.
