Building a Zero Trust Container Platform in Azure

Zero trust changes the way you design container platforms. You stop assuming anything is safe. Every identity must prove itself. Every resource must be isolated. Every boundary must be explicit. A modern Azure platform gives you the pieces, but it does not give you a safe system by default. You must assemble the environment layer by layer until nothing passes without proof.

A mature zero trust platform in Azure uses two complementary environments. Azure Container Apps provides a managed control plane that handles scaling, ingress, certificates, identity, and workload isolation without the operational drag of Kubernetes. AKS provides granular control for workloads that need custom networking, privileged sidecars, message brokers, private ingress controllers, or latency sensitive services. The two environments serve different purposes. When you design them together, you give each workload the environment that matches its shape. The platform becomes flexible without sacrificing discipline.

The foundation begins with identity. Zero trust starts with the principle that no workload should use secrets. A container should never store a connection string, API key, or password. Instead it should authenticate using workload identities that Azure can verify cryptographically. This means every Container App uses a managed identity. Every AKS workload uses workload identity federation. Every pipeline that pushes an image authenticates to Azure Container Registry using OIDC with no stored credentials. When everything authenticates with signed identity tokens, you close the first major attack path. A compromised container cannot steal a secret that does not exist.

Once identity is in place, you tighten the supply chain. Containers are only trustworthy if you control the images. Azure Container Registry supports content trust. Your CI pipeline signs images using Notation. When an image reaches the registry, it arrives with a signature bound to the digest. The signature becomes the source of truth. Container Apps and AKS then enforce signature verification. Any unsigned image is rejected. Any image with mismatched metadata is blocked. The orchestrator no longer trusts the registry alone. It trusts the cryptographic identity that your pipeline produced. This step removes entire classes of supply chain attacks. A poisoned dependency cannot overwrite an image digest. A malicious actor cannot replace an image in the registry without breaking the signature.

You also need to remove uncertainty from the build itself. A secure image must be reproducible. You achieve this by locking base images by digest. You avoid floating tags. You build .NET services with deterministic restore and locked NuGet dependencies. You use multi stage builds that isolate build tools from runtime. You trim the application. You produce a small, predictable executable in a distroless runtime image. Each image has a clear lineage. When you audit the container, you can explain why every file exists. Predictability becomes a security guarantee because unpredictable containers hide the unknown.

Networking forms the next layer. You do not allow workloads to talk freely. Zero trust networking begins with private environments. Container Apps runs inside an internal environment contained by a locked down VNET. It has no public ingress. Ingress only flows through an Application Gateway with WAF enabled or through an Azure Front Door instance with strict routing rules. AKS sits inside a sibling network segment. It uses Azure CNI with dedicated subnets. Pods receive IP addresses that Azure understands. Network security groups restrict movement between subnets. Private endpoints control access to databases, service buses, and internal APIs. No workload can reach the public internet unless you explicitly allow it. Outbound traffic either flows through Azure Firewall or gets blocked. This turns the network into a verification layer. Traffic paths become predictable. Unauthorised access attempts become visible.

Two orchestrators require one policy engine. Azure Policy sits above both environments. It enforces that images must be signed. It enforces that container registries must be private. It enforces HTTPS ingress. It denies hostPath mounts. It blocks privileged containers in AKS. It blocks sidecars that run with elevated permissions. Policy becomes the first guard. Anything that violates the platform rules never reaches production. Developers gain clarity because the platform no longer accepts unsafe workloads. Security becomes a constraint baked into the environment.

A zero trust architecture also needs runtime controls. Containers fail. Some failures indicate ordinary bugs. Others indicate an attack. You cannot tell the difference if the environment lacks visibility. Container Apps provides request telemetry, environment logs, and revision history. AKS provides node-level and pod-level audit events. You push these logs into a central workspace. From there you create behavioural baselines. A healthy container starts within a known window. It opens a predictable set of outbound ports. It accesses a small range of internal dependencies. Anything outside these patterns triggers an inspection. This method works because a hardened environment has fewer legitimate behaviours. When you reduce the normal path, anomalies become clearer.

The relationship between AKS and Container Apps becomes important here. Container Apps handles most services because it reduces the operational load. AKS carries the specialised workloads. You do not run general web APIs in AKS unless you need capabilities the managed platform cannot provide. When you shift workloads into Container Apps by default, the blast radius becomes smaller. The majority of your applications run inside a managed sandbox with sealed boundaries. AKS becomes a controlled environment instead of a dependency for everything. Zero trust benefits from this split because you reduce complexity where you can and apply granular control where you must.

The next boundary is the connection between developer machines and the platform. Zero trust assumes developers should never authenticate directly to production clusters. They authenticate to Azure. Azure issues tokens. Tokens allow controlled, short-lived access. You use role assignments to limit what a human can do. You log every action. You avoid kubectl wherever possible by using GitOps for deployment. When AKS receives changes from a Git repository rather than from direct human commands, unapproved modifications cannot sneak in quietly.

To make the architecture clearer, it helps to map the trust flow.

The diagram shows every step requires proof. Nothing runs without identity. Nothing runs without signature. Nothing reaches infrastructure without policy.

At this point, you introduce defence in depth. You assume a container can still be compromised. You assume an attacker may reach a running process. The question becomes how far they can move. In Container Apps they face an immutable runtime with no shell. They cannot write to the root filesystem. They cannot mount disk. They cannot issue outbound calls unless you allowed them. Capabilities are limited because the managed platform does not expose them. In AKS you set your seccomp profiles. You drop capabilities. You run each pod with a read only root filesystem. You enforce non root users. You use the pod security admission controller to reject workloads that ask for dangerous privileges. By controlling the runtime, you reduce the space an attacker can explore.

You also protect data access paths. Databases, queues, caches, and internal APIs insist on workload identity. They do not accept keys. They do not trust internal networks alone. They evaluate tokens that Azure issues. This blocks lateral movement through credential theft. Even if a container is compromised, the attacker cannot extract secrets because none exist. They cannot reuse the identity token because it expires quickly. They cannot impersonate the service across long time windows because identity is bound to the workload that Azure created. A .NET application inside this environment becomes simpler to defend. It starts quickly. It reads configuration from Azure. It connects using managed identity. It logs to the central workspace. It runs inside a runtime image that contains nothing except the application and the libraries it needs. It cannot spawn a shell. It cannot load native tooling. It cannot reach the internet. The container’s behaviour becomes predictable. That predictability is the security boundary. The architecture becomes stronger when you integrate continuous verification. You scan images in the registry to detect new vulnerabilities. You monitor supply chain sources. You rebuild images regularly. You track dependency changes through SBOM diffs. When a vulnerability appears, you know which artefacts are affected. You eliminate guesswork. Your platform remains ahead of supply chain attacks because each layer is small, signed, and auditable.

With zero trust you build a chain where each link reinforces the others. Identity reinforces networking. Networking reinforces policy. Policy reinforces the build pipeline. The build pipeline reinforces the registry. The registry reinforces the orchestrator. The orchestrator reinforces runtime boundaries. If one link weakens, the others slow the attacker down. Designing a zero trust container platform in Azure becomes easier when you accept that most workloads belong in Container Apps and only specialised workloads belong in AKS. This reduces the complexity of your attack surface. It also forces clarity into your architecture. You give developers a safe platform by default. You give infrastructure engineers the tools to handle advanced cases. You give the organisation a trustworthy environment built on clear boundaries instead of hope.

Once the platform reaches this stage, operations become quieter. Incidents become easier to diagnose because the unknowns shrink. Random behaviour stands out. Compromised workloads expose themselves through abnormal patterns.

Containers become predictable.

Predictability becomes security.

This is how you build a zero trust container platform in Azure. Not with one tool. Not with one setting. With a chain of small, verifiable steps that transform the platform into something attackers cannot navigate.