Kubernetes Zero Trust Architecture: Identity, Network Policy, mTLS and Admission Control on EKS, AKS and GKE (2026)

Zero trust in Kubernetes means no workload is trusted because of where it runs. Every request, pod-to-pod or pod-to-cloud, is authenticated, authorised and encrypted, and the cluster only runs what has been verified. The default Kubernetes install is the opposite: a flat network where every pod can reach every other pod, service accounts with tokens mounted everywhere, and an API server that accepts any image the deployer names.

This guide lays out the controls that make up a zero trust Kubernetes architecture, in the order we implement them for clients on EKS, AKS and GKE, with the trade-offs that matter in production. It assumes a working cluster and a team that already deploys with a pipeline; if not, start with our Kubernetes consulting for AWS guide.

The principles applied to a cluster

• Identity is the perimeter. Every workload has a cryptographic identity (a service account bound to a cloud IAM role, a SPIFFE ID in a mesh) and every call is authorised against it.
• Deny by default. Network policy, RBAC, admission and egress all start closed and open per need.
• Encrypt everywhere. In transit between pods, to managed services, and at rest for secrets and volumes.
• Verify what runs. Only signed images from approved registries, scanned, with no privileged containers, admitted.
• Assume breach. Runtime detection, short-lived credentials, and segmentation that keeps a compromised pod from becoming a compromised cluster.
• Observe and audit. API audit logs, network flow logs and mesh telemetry retained and alerted on.

1. Workload identity: no static credentials

The first control is removing long-lived secrets from pods. Each provider maps a Kubernetes service account to a cloud identity so pods obtain short-lived tokens automatically:

• EKS: IAM Roles for Service Accounts (IRSA) or the newer EKS Pod Identity, with one IAM role per workload scoped to the exact S3 buckets, queues and tables it needs.
• AKS: Microsoft Entra Workload ID, federating a service account to a managed identity.
• GKE: Workload Identity Federation for GKE, binding a Kubernetes service account to a Google service account.

Disable automatic service-account token mounting (automountServiceAccountToken: false) on every pod that does not talk to the API server, use projected tokens with short expiry and audience for those that do, and delete the default service account permissions in every namespace. Kubernetes RBAC is then scoped per namespace and per workload; cluster-admin is reserved for the platform team through the cloud IAM mapping, with no shared kubeconfigs.

2. Network policy: default deny, then allow

Kubernetes NetworkPolicy is enforced by the CNI. On EKS use the VPC CNI's network policy support or Cilium; on AKS use Azure CNI with network policy (Azure or Calico) or Cilium; on GKE use Dataplane V2 (Cilium-based). Apply a default-deny ingress and egress policy to every namespace, then allow specific flows:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: payments }
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

Then per workload: ingress from the ingress controller or the calling service only, egress to the database service, DNS (kube-dns on 53), and the specific external endpoints it needs. Cilium adds L7 and FQDN-based egress rules (toFQDNs) so a pod can reach api.stripe.com and nothing else, plus Hubble flow logs that show what would be blocked before you enforce. Cloud-level controls (security groups for pods on EKS, NSGs on AKS) sit underneath for node-level and VPC-level segmentation.

Egress is where most teams stop short. A compromised pod with unrestricted egress can exfiltrate data and fetch tooling; FQDN egress policy or an egress gateway closes that.

3. mTLS and service mesh: encrypt and authenticate pod-to-pod

Network policy controls which pods may talk; mTLS proves who is talking and encrypts it. A service mesh issues each workload a certificate tied to its identity (SPIFFE), rotates it automatically, and enforces mutual TLS with authorisation policies at L7. Options in 2026:

• Istio (including ambient mode, which removes the per-pod sidecar for most traffic) for the richest policy model and the largest ecosystem.
• Linkerd for simplicity and low overhead where L7 authorisation needs are modest.
• Cilium's mutual authentication with WireGuard or IPsec node-to-node encryption, for teams that want encryption and identity without a full mesh.

Set the mesh to STRICT mTLS cluster-wide, then write authorisation policies that mirror the network policies at the identity level: the checkout workload may call payments on POST /charge and nothing else. Managed offerings (Istio on GKE via Anthos Service Mesh, Istio add-on on AKS, Istio on EKS via the AWS-supported distribution) reduce the operational cost. Mesh adoption is the largest change on this list; do it namespace by namespace with permissive mode first.

4. Admission control: only verified workloads run

Policy engines intercept every API request before it is persisted. Kyverno (Kubernetes-native YAML policies) or OPA Gatekeeper (Rego) enforce:

• Images only from your registries, signed with cosign and verified against your keys or Sigstore identity.
• No privileged, no hostPID/hostNetwork/hostPath, read-only root filesystem, non-root user, dropped capabilities, seccomp profile set: the Pod Security Standards restricted profile, enforced rather than warned.
• Required resource requests and limits, required labels and owner annotations, no latest tags.
• No service account token mounts unless explicitly annotated.
• Ingress and Gateway resources only with TLS.

Pod Security Admission (built in) covers the baseline profiles; Kyverno or Gatekeeper add the image verification and organisational rules. Run new policies in audit mode, review the report, then enforce. Policies live in Git and deploy through the same GitOps flow as workloads.

5. Secrets: out of manifests, short-lived where possible

Secrets in plain Kubernetes Secret objects are base64, not encrypted, and readable by anyone with namespace access. Store them in AWS Secrets Manager, Azure Key Vault, Google Secret Manager or HashiCorp Vault, and deliver them with the External Secrets Operator or the Secrets Store CSI driver, using workload identity from step 1 so no bootstrap credential is needed. Enable envelope encryption of etcd secrets with a KMS key on every provider. Prefer dynamic, short-lived credentials (Vault database secrets, IAM tokens) over static passwords, and rotate anything static on a schedule.

6. Supply chain: verify before deploy

Zero trust extends to the artefacts. In the pipeline: build reproducibly, generate an SBOM (Syft), scan images and dependencies (Trivy, Grype), sign images and attestations with cosign, and record provenance (SLSA). In the cluster: admission control (step 4) verifies the signature and can require an attestation that the scan passed. Base images come from a curated set rebuilt on a schedule; application images are minimal (distroless or scratch) so there is little for an attacker to use. Our CI/CD pipeline optimization guide covers doing this without slowing the pipeline.

7. Runtime detection and response

Assume something gets through. Falco or Tetragon (eBPF-based) detect unexpected process execution, shell spawns in containers, sensitive file reads and unexpected network connections at the kernel level, and can kill the offending process. Cloud-native options (GuardDuty EKS Runtime Monitoring, Defender for Containers, GKE Security Posture and Container Threat Detection) integrate with the provider's security console. Alerts route to the NOC or SOC with the pod, namespace, image and owner attached. Node images are hardened and short-lived (Bottlerocket, Azure Linux, Container-Optimized OS), rotated on a schedule so drift cannot accumulate.

8. Control plane and node hardening

• Private API server endpoint, or public with a tight allow-list, and authentication through cloud IAM only.
• API audit logging enabled and shipped to the SIEM; alert on RBAC changes, secret reads and exec into pods.
• Nodes in private subnets with no public IPs, instance metadata (IMDS) restricted so pods cannot assume the node's role (IMDSv2 with hop limit 1 on EKS, or block via network policy).
• Managed node groups or autopilot modes so the provider patches the control plane and node OS; upgrade on the provider's release cadence, never more than one minor version behind.
• Separate clusters, or at minimum separate node pools and namespaces with policy, for production and non-production.

Implementation order

For an existing production cluster, this sequence delivers the most risk reduction earliest with the least disruption:

1. Workload identity and RBAC clean-up (weeks 1 to 2). No application change if the SDKs already use the default credential chain.
2. Pod Security Admission restricted in audit, then enforce; Kyverno image verification (weeks 2 to 4).
3. Default-deny network policy per namespace with allow rules derived from flow logs (weeks 3 to 6).
4. Secrets to an external store with the operator; etcd encryption (weeks 4 to 6).
5. Runtime detection and audit-log alerting (weeks 5 to 7).
6. Supply-chain signing and attestation in the pipeline (weeks 6 to 8).
7. Service mesh with mTLS, namespace by namespace (weeks 8 onward).

Each step leaves the cluster in a better state than the last. Steps 1 to 5 are achievable on most estates in two months with no application code changes.

Compliance mapping

The controls above are what auditors look for under ISO 27001 A.8 and A.13, PCI DSS requirements 1, 2, 6, 7, 8 and 10 for in-scope clusters, SOC 2 CC6 and CC7, and the CIS Kubernetes and provider-specific benchmarks. Certification work is delivered by our sister firm PraxisQ Consulting; the cluster controls and their evidence (policy reports, audit logs, flow logs, signed provenance) are built and operated here.

Frequently asked questions

What is zero trust in Kubernetes?

An architecture where no pod is trusted by default: every workload has a verified identity, all traffic is authenticated and encrypted, network access is denied unless allowed, only signed and policy-compliant images run, and runtime behaviour is monitored.

Do we need a service mesh for zero trust?

Not on day one. Workload identity, network policy, admission control and secrets management deliver most of the value. A mesh adds identity-based L7 authorisation and mTLS, and is the right later step for multi-team clusters.

Is Kubernetes NetworkPolicy enough for network segmentation?

For L3 and L4 segmentation, yes, when the CNI enforces it. For FQDN-based egress and L7 rules, use Cilium or a mesh. Pair it with cloud-level security groups or NSGs for node and VPC segmentation.

How do we handle zero trust on EKS specifically?

EKS Pod Identity or IRSA for identity, the VPC CNI network policy or Cilium for segmentation, IMDSv2 hop limit and private endpoints for the control plane, Kyverno with cosign verification for admission, and GuardDuty runtime monitoring or Falco for detection.

Can Techtweek implement this for us?

Yes. Zero trust Kubernetes architecture is delivered through our DevOps consulting services, with the cluster then run under our cloud infrastructure services and watched by the NOC.