Draw the complete build-to-runtime trust chain

An Azure Kubernetes Service workload begins before any pod starts. Source code enters a repository, a pipeline builds an image, the image is stored in Azure Container Registry, a deployment controller pulls it, Kubernetes schedules pods, and those pods call databases and cloud services. A weakness at any transition can defeat controls further down the chain. Start by identifying which identities can change source, sign or push images, change the cluster, deploy workloads and access customer data at runtime.

The AKS security concepts guide treats the registry, cluster and running application as parts of one security lifecycle. Preserve that separation: a build pipeline needs permission to publish approved artifacts, a node or workload needs only the ability to retrieve the image it runs, and an application service account should not inherit the ability to administer its own Kubernetes control plane. Using one broad service principal for every hop collapses those boundaries.

Define one demonstrable threat scenario, such as a compromised CI job publishing a modified image or a breached pod retrieving a Key Vault secret it should not need. This will determine what to test: pipeline permissions, registry pull restrictions, image provenance, network policies, workload token issuance and detection. The cloud security architecture approach helps map shared platform controls separately from workload-owned application authorization.

Restrict registry credentials and image publishing authority

Azure Container Registry stores images and related artifacts that become executable production code. Prefer Microsoft Entra-based authentication and scoped registry roles where supported, with separate push and pull identities. Microsoft's ACR best practices recommend using role-based access and separating deployment pull operations from build-time push privileges. The registry's admin account is not an appropriate everyday credential for pipelines or clusters.

Review the permissions that allow a pipeline to overwrite tags. A deployment that simply pulls latest can receive a new image without the workload's own deployment manifest changing. Use approved image versions or immutable digests in release workflows where appropriate, and apply artifact provenance and signing practices according to organizational tooling. A trusted image tag is a naming convention; the resolved digest identifies a particular set of image bytes.

For an incident exercise, inject an unauthorized image tag into a test repository or attempt to push from an identity with only pull rights. Confirm the operation fails and the attempted action produces useful audit evidence. Then test normal deployment using the designated identity. Keep image retention and quarantine practices aligned with the ability to reconstruct what ran during a security investigation.

Harden the AKS control plane and human administration

Cluster administration requires several independent checks: Microsoft Entra login to the cluster where configured, Kubernetes RBAC permissions to specific API operations, network reachability to the API server, and safe handling of kubeconfig or tokens. Avoid handing every developer cluster-admin privileges merely to simplify troubleshooting. Separate production deployment roles, read-only diagnostics, namespace operations and emergency cluster administration according to actual responsibilities.

An unauthorized user should fail to create a privileged role binding, read secrets outside an approved namespace or modify admission controls. Verify these denials with a representative low-privilege identity rather than trusting an RBAC YAML review alone. Kubernetes RBAC and Azure resource roles are different planes: permission to manage the Azure AKS resource is not necessarily identical to authorization for every Kubernetes API object, so reviewers should analyze both.

Network access to the API server also deserves deliberate restriction. Select supported private-cluster and authorized-access patterns that fit operations, maintenance and disaster recovery. A private cluster can reduce exposure, but administrators still need an approved DNS and network route during an outage. Design break-glass access and audit the actions that occur through it instead of permanently broadening the API endpoint to make emergency recovery convenient.

Keep nodes, admission and pod privileges constrained

AKS manages important infrastructure components, but the customer still makes decisions about node images, upgrades, workload permissions, container runtime exposure and application configuration. Use supported upgrade and node-hardening processes and define owners for cluster lifecycle. A node pool hosting internet-facing services may have different isolation and patching urgency from an internal batch pool with no customer data.

Use pod security standards, admission controls and other supported policy mechanisms to prohibit privileged containers, unneeded host mounts, host networking and capabilities that are inconsistent with the workload. Run applications as non-root where feasible, restrict filesystem write access and avoid mounting a broad host path merely to solve a debugging problem. The exact restrictions should be compatible with the application and the service's supported AKS configurations.

Validate policy with both a conforming deployment and a deliberately nonconforming test pod. Record whether admission rejected the pod or whether the runtime allowed it with unexpected privileges. Admission controls are effective only when they remain enforced as deployment tools and operators evolve. Keep administrative exceptions narrow, time-bound and visible to security owners.

Use workload identity instead of static secrets for cloud resources

A service running in AKS often needs storage, messaging, Key Vault or a database. Prefer supported Microsoft Entra workload identity federation rather than placing long-lived cloud credentials in Kubernetes Secrets. Link a narrowly scoped Kubernetes service account to the correct Entra principal, and grant only the Azure roles required for the workload's real business actions. The federation configuration is sensitive because issuer, subject and audience determine which pod identity can request the downstream token.

Kubernetes Secrets are not a reason to store every cloud credential inside the cluster. Even encrypted-at-rest secrets may be available to principals that can query the Kubernetes API or compromise a node. Reduce secret volume, restrict Kubernetes RBAC and use an appropriate secret-store integration for values that must still exist. The managed identity and least privilege guidance explains why the absence of a password does not remove the need to review RBAC scope.

Test a token from a pod with the correct service account against one allowed resource and one disallowed resource. Repeat from a different namespace or service account to confirm no workload can impersonate the approved principal merely by copying a deployment. Review federated credential records after namespace changes or service retirement so old trust relationships do not remain usable indefinitely.

Segment pod egress and protect the data path

Network policies can restrict communication between pods and namespaces, and Azure networking controls govern traffic beyond the cluster where supported. Decide which pods need to contact the internet, which should reach private PaaS endpoints and which should communicate with each other. Default-open service-to-service networking creates unnecessary lateral-movement opportunities if one application is compromised.

Design DNS, outbound routing, load balancing, ingress protection and private endpoint resolution as part of this model. An AI inference API, for example, might need private access to Azure SQL and Azure Storage but no direct outbound route to arbitrary internet destinations. If egress must traverse a firewall or proxy, verify the cluster's expected control-plane and platform dependencies still work; indiscriminate blocking can cause upgrade and DNS failures.

Run both positive and negative tests. Check that the approved frontend-to-API and API-to-database paths work, that a test pod in another namespace cannot reach the sensitive service, and that internet egress is constrained as designed. The Azure network security at scale article is a useful companion for routing and distributed ownership outside the AKS boundary.

Deploy Defender for Containers with clear coverage expectations

Microsoft Defender for Containers spans posture, vulnerability assessment and supported runtime threat protection for container estates. These layers should not be confused. Registry or image findings are about components and known vulnerabilities; cluster configuration findings expose control weaknesses; runtime alerts describe observed suspicious behavior. Each signal has different prerequisites, update frequency and potential blind spots.

Inventory which registries, images, clusters, node pools and running workloads are actually covered. Agentless image vulnerability scanning may assess a registry artifact while the running pod uses an older image digest or an image from another registry. Runtime monitoring can depend on supported components and onboarded environments. Check the service's current feature matrix before claiming uniform coverage across Azure, AWS, GCP and local clusters.

Validate one policy misconfiguration in a safe test namespace and one approved vulnerability or detection scenario supplied by Microsoft for that environment. Confirm the recommendation or alert appears, includes resource identity and reaches an operational owner. Do not deliberately deploy active malware or an uncontrolled privileged container in production just to make a monitoring dashboard show activity. Use test cases proportionate to the risk and keep a rollback path.

Make deployment gates and incident response reproducible

The deployment pipeline should test artifacts before they arrive in production: vulnerability thresholds, approved registries, image provenance, manifest policy, service account rights and resource requests. A vulnerability or policy exception should have a named owner, reason and review date. Avoid building a pipeline that every team must bypass because the exception route is undocumented or the scanner cannot handle real workloads.

Define containment actions for the Kubernetes layer: quarantine a namespace, scale down a compromised deployment, revoke workload identity access, block egress, rotate an exposed credential or replace a node through a supported method. Incident responders should also preserve pod, image, Kubernetes API and cloud identity evidence where feasible. Terminating a compromised pod too early can destroy context while leaving the broad cloud role that enabled the incident unchanged.

Test rollback using an earlier signed image digest and a known deployment manifest, then confirm the restored workload can access only its intended resources. The security objective is not merely that a new image deployed successfully but that the entire supply chain remains explainable. SC-500 candidates should be able to trace identity, authorization, registry integrity, admission policy, networking, runtime protection and recovery as one end-to-end Azure workload security design.