Containers changed how software ships: portable, resource-efficient, quick to scale and ideal for microservices. Kubernetes orchestrates those containers at scale and Azure Kubernetes Service (AKS) takes the operation of the control layer off your hands. Microsoft manages the control plane; you manage the nodes and everything running on them.
That split is exactly where the misunderstanding lives: AKS reduces operational effort, not your responsibility for securing the cluster. The following areas decide, in practice, whether an AKS cluster holds.
Where the responsibility boundary runs
Before settings, the sober split. It explains why “managed” Kubernetes still means work.
| Microsoft | You | |
|---|---|---|
| Control plane (API server, etcd, scheduler) | Operation, patching, availability | Access control and exposure |
| Worker nodes | Providing the node image | Updating, hardening, monitoring |
| Container images | nothing | Provenance, scanning, signing |
| Workloads and RBAC | nothing | entirely |
| Network policies | nothing | entirely |
| Secrets and identities | Platform mechanisms | Configuration and rotation |
The rows where Microsoft contributes nothing are where real incidents come from. It’s the same pattern as object storage, where the platform doesn’t fail, the configuration does: see S3 Bucket Security.
1. Secure access to the control plane
- Integrate Entra ID (Azure AD) for authentication: no local cluster credentials
- Configure Role-Based Access Control (RBAC) rigorously, on a least-privilege basis
- Enforce TLS encryption for all communication
- Restrict API server access to authorised IP ranges (authorized IP ranges / private cluster)
Two points deserve explanation.
Local account credentials are the quiet bypass. A cluster can be configured so that a local admin account keeps working alongside Entra ID. That leaves an access path subject to neither Conditional Access nor MFA nor central revocation. Anyone introducing Entra ID should disable the local path in the same step, otherwise the introduction is an addition rather than a replacement.
A private cluster works, but isn’t free. An API server that isn’t publicly reachable removes an entire attack path. It does require network connectivity for build agents, management tooling and emergency access. Plan that in advance or you end up building exceptions that eat the benefit again. Where a private cluster isn’t an option, authorised IP ranges are the minimum.
2. Harden the worker nodes
- Apply OS updates for Linux nodes automatically and promptly
- Apply standard VM protection: Azure Policy, firewalls, endpoint protection
- Patch Windows nodes regularly: they’re easy to forget
Nodes differ from classic servers in one respect: they should not be maintained but replaced. Node image upgrades swap nodes for fresh instances instead of pulling packages onto running systems. That removes the configuration drift which otherwise accumulates over months, and makes patch level reproducible.
From which follows the second principle: no interactive access to nodes. Connecting to a node over SSH to “just check something” creates exactly the state the replacement model is meant to prevent. Diagnosis belongs in logs and metrics, not on the node’s command line.
How patch levels can be tracked reliably across distributed systems at all is covered in Cloud Patch Management.
3. Secure pods and containers
- Set resource limits so a compromised pod can’t seize the whole node’s resources
- Source container images from trusted registries and scan them for vulnerabilities: ideally in the CI/CD pipeline, not only at runtime
- Enforce Pod Security Standards; avoid privileged containers
On Pod Security Standards: the former PodSecurityPolicies were removed in Kubernetes 1.25. Pod Security Admission takes their place, with three levels, privileged, baseline and restricted, set per namespace. A sensible start is enabling restricted in warn and audit mode first: you see which workloads would fail without interrupting operations.
What a restrictive profile means in practice: no privileged mode, no host namespaces, no write access to the container’s root filesystem, execution as a non-root user, Linux capabilities reduced to what is needed. Every one of those constraints shrinks what an attacker can do at all after successful execution inside a container.
On image scanning: it belongs in the pipeline, because a finding there is still a decision and at runtime it is only an alert. Pair it with a rule that admits only images from your own registry. Without that rule, scanning stays a recommendation that one line in a manifest can bypass.
A scanner finds known vulnerabilities in packages, but not faulty permissions or logic flaws. Where that boundary runs is described in Vulnerability Scan: What It Delivers.
4. Segment the network
- Choose deliberately between the network models (kubenet vs. Azure CNI)
- Define network policies to limit east-west traffic between pods
- Put a web application firewall in front and secure cluster connections
The most important sentence in this section: Kubernetes permits every connection between all pods by default. Without network policies, a cluster is a flat network. A compromised pod in an unimportant application therefore reaches every other application in the cluster, databases and internal services included.
The usual starting point is a default-deny rule per namespace, followed by explicit allowances for the connections actually needed. It is work, but it is the measure that turns a compromise into a contained incident rather than a cluster-wide one.
Equally important and frequently overlooked: outbound traffic. A cluster free to call anywhere on the internet makes both tool delivery and data exfiltration easier. Controlled egress paths are not a luxury.
5. Identities and secrets
This area is missing from many hardening checklists and produces a disproportionate share of findings.
- Workload identity instead of stored credentials. Pods should authenticate to Azure services through federated identities rather than carrying long-lived keys in a manifest or an image.
- Kubernetes secrets are not encrypted, they are base64-encoded. Used without additional measures, they are stored readable. Anything worth protecting belongs behind an external vault with rotation.
- No credentials in images. An image travels through registries, caches and developer machines. What goes in is practically impossible to retrieve.
6. Logging and detection
Hardening prevents some attacks. The rest you have to see.
Enable the control plane diagnostic logs, in particular the Kubernetes audit log. It shows who changed which resource and when, making it the only defensible source for what actually happened during an incident.
Those logs are only useful if they land where correlation happens and are retained long enough. Which sources are worth ingesting for detection and which only generate cost is covered in Which Log Sources Does a SIEM Actually Need.
Watch in particular for: changes to RBAC bindings, creation of privileged pods, access to secrets, and exec calls into running containers. Those are the events that show up in nearly every compromise.
The real point: Kubernetes security isn’t a checkbox
AKS lowers the barrier to entry, but comprehensive Kubernetes hardening stays complex and demands deliberate work. Misconfigured RBAC, exposed API servers, unscanned images and missing network policies are among the most common entry points into container environments. The tricky part: much of it is invisible until someone exploits it.
The CIS Kubernetes Benchmark works well as an assessment frame. It doesn’t replace your own risk analysis, but it gives you a defensible baseline list to measure current state against.
If you want the configuration tested against a real attack, the rules and limits for that are in Penetration Testing in the Public Cloud.
How Cloud Cape helps
Container and cloud misconfigurations are a textbook case for Continuous Threat Exposure Management: discover continuously, prioritise by real risk and validate with real attack techniques, instead of hoping once a year. Our Continuous Threat Exposure Management covers AKS clusters, images and cloud configuration; where it needs to go deeper, our red team tests the clusters offensively too.
Talk to us about Exposure Management. We make the misconfigurations visible before an attacker does.