AKS Identity and Security#

AKS identity operates at three levels: who can access the cluster API (authentication), what they can do inside it (authorization), and how pods authenticate to Azure services (workload identity). Each level has Azure-specific mechanisms that replace or extend vanilla Kubernetes patterns.

Entra ID Integration (Azure AD)#

AKS supports two Entra ID integration modes.

AKS-managed Azure AD: Enable with --enable-aad at cluster creation. AKS handles the app registrations and token validation. This is the recommended approach.

Container Image Scanning#

Every container image you deploy carries an operating system, libraries, and application dependencies. Each of those components can have known vulnerabilities. Image scanning compares the packages in your image against databases of CVEs (Common Vulnerabilities and Exposures) and tells you what is exploitable.

Scanning is not optional. It is a baseline hygiene practice that belongs in every CI pipeline.

How CVE Databases Work#

Scanners pull vulnerability data from multiple sources: the National Vulnerability Database (NVD), vendor-specific feeds (Red Hat, Debian, Alpine, Ubuntu security trackers), and language-specific advisory databases (GitHub Advisory Database for npm/pip/go). Each CVE has a severity rating based on CVSS scores:

Security Hardening a Kubernetes Cluster#

This operational sequence takes a default Kubernetes cluster and locks it down. Phases are ordered by impact and dependency: assessment first, then RBAC, pod security, networking, images, auditing, and finally data protection. Each phase includes the commands, policy YAML, and verification steps.

Do not skip the assessment phase. You need to know what you are fixing before you start fixing it.

Phase 1 – Assessment#

Before changing anything, establish a baseline. This phase produces a prioritized list of findings that drives the order of remediation in later phases.

Zero Trust Architecture#

Zero trust means no implicit trust. A request from inside the corporate network is treated with the same suspicion as a request from the public internet. Every request must prove who it is, what it is allowed to do, and that it is coming from a healthy device or service — regardless of network location.

This is not a product you buy. It is an architectural approach that requires changes to authentication, authorization, network design, and monitoring.

Admission Controllers and Webhooks#

Every request to the Kubernetes API server passes through a chain: authentication, authorization, and then admission control. Admission controllers are plugins that intercept requests after a user is authenticated and authorized but before the object is persisted to etcd. They can validate requests, reject them, or mutate objects on the fly. This is where you enforce organizational policy, inject sidecar containers, set defaults, and block dangerous configurations.