A Practical Checklist for Zero Trust Networking in Kubernetes

Zero trust networking in Kubernetes means authenticating callers and explicitly authorizing access rather than trusting traffic simply because it originates inside the cluster. This checklist gives platform teams a practical order to work through.

Map east-west traffic before you lock anything down

You can't enforce policy on unseen flows. Clusters often carry leftover connections from debug ports, old CronJobs, and one-off tests. Starting with deny rules before mapping those flows can break production.

Inventory east-west traffic between services. Compare signals from Kubernetes diagnostics, Grafana, Kiali, and Linkerd Viz. Include Deployments, StatefulSets, DaemonSets, and CronJobs, plus DNS lookups to kube-dns or CoreDNS that pods need. Track ingress and egress too, since north-south traffic can slip past internal controls.

That inventory is your baseline.

Record each caller, receiver, port, and protocol for your target namespace
Label DNS queries, metrics scrapes, health probes, and controller traffic as infrastructure flows
Mark plaintext HTTP and undocumented callers for cleanup before enforcement
Version the inventory and get service owners' sign-off before writing rules

Done when you can name every allowed caller for one critical service, backed by observed traffic and owner review. Include scheduled jobs and recovery paths that may not appear during a short observation window. Keep the inventory current as deployments change.

Treat NetworkPolicy as a floor, not a solution

Kubernetes NetworkPolicy can't deliver zero trust alone. It selects pods and namespaces using labels and can use IP blocks, filtering supported traffic at L3 and L4 by address and port. It can't check cryptographic workload identity or TLS.

Enforcement depends on your CNI plugin. Without NetworkPolicy support, the YAML does nothing, with no error to warn you. Policies are additive, so a stray allow rule can reopen a path, leaving you debugging labels and selectors across namespaces.

A network plugin may offer additional visibility, encryption, or policy features beyond the standard API. Evaluate those features separately: network-level filtering and encryption do not automatically establish authenticated application identities or least-privilege access to service operations.

Confirm your CNI enforces NetworkPolicy and log its version
Apply default-deny ingress and egress in namespaces you're hardening
Restrict NetworkPolicy and pod-label changes through RBAC, approval workflows, Git history, and alerts
Test allowed and blocked traffic, then keep those tests in CI

Done when default-deny is active and tests show blocked paths actually drop. You still need identity.

Give each workload a short-lived identity

Zero trust as defined in NIST SP 800-207 starts with identity, not network location. A caller presents a verifiable credential, then receives only the access its authorization policy permits, rather than gaining permission simply by belonging to the cluster.

The credential's practical unit is usually the ServiceAccount. Linkerd mints automatically rotating per-pod certificates, but their identity maps to the ServiceAccount shared by the service's replicas. Replicas can therefore share an authorization principal while holding separate certificates. Do not assume deleting a ServiceAccount immediately invalidates every issued certificate; plan policy-based access removal and account for credential expiry.

Prefer short lifetimes and automated issuance over long-lived tokens or shared secrets. SPIFFE and SPIRE provide x509 identities; a mesh offers another path tied to Kubernetes ServiceAccounts. You don't need SPIFFE everywhere, but you must understand each identity's origin, lifetime, and rotation.

Map each service to a dedicated ServiceAccount; avoid the default for workloads
Automate certificate renewal through your identity system, and use projected short-lived ServiceAccount tokens with application reload support where tokens are needed
Restrict ServiceAccount creation, Role binding, label changes, and token mounting
Document root and issuer rotation plans and ownership

Done when services in the rollout scope use the intended renewable credentials, any legacy exceptions have owners and migration plans, and lifetimes meet your tested bound. Test renewal and failure recovery before production enforcement.

Require mTLS and test that plaintext actually fails

Mutual TLS proves workload identity and encrypts east-west traffic. Each service presents its identity and verifies its peer. Failed verification must mean no data.

Teams wanting production-grade workload identity and automatic mTLS without building infrastructure often adopt Linkerd, which provides zero trust network security for kubernetes through ServiceAccount-based identities and automatically rotating per-pod certificates. This reduces manual certificate work, but installing a mesh alone does not prove that access is denied by default. Configure authorization to require the intended authenticated identities on protected ports, and test the result.

Understand the gaps. A mesh doesn't encrypt unmeshed pod traffic, cover health checks or metrics ports bypassing the proxy, or replace CNI policy and ingress and egress controls. Root and issuer rotation still needs your runbook before certificates expire. mTLS authenticates callers; authorization determines what they may do.

Require authenticated mesh identities on protected ports in your first namespace using the implementation's supported authorization policies
Keep explicit exceptions for DNS, kubelet probes, metrics scrapes, and controller webhooks; review monthly
Test that allowed meshed callers succeed while plaintext and unmeshed callers fail
Alert on cert expiry, TLS failures, rotation errors, and plaintext fallback

Done when an unauthorized plaintext caller cannot reach a protected service and dashboards show authenticated TLS between meshed peers in scope. Never fix failures by downgrading to plaintext. Isolate clients that can't use mTLS and plan migration, rather than leaving permanent holes.

Add L7 rules only where your proxy and protocol allow

mTLS handles authentication. Authorization needs separate rules because an authenticated identity with broad access can still do damage.

A mesh or gateway can authorize HTTP and gRPC routes using method, path, and authenticated identity where its proxy understands the protocol. Allowing the frontend identity to GET /orders while denying POST is more precise than opening a port. It depends on protocol parsing and won't work for opaque TCP or custom UDP with no visible methods or paths.

For databases, caches, queues, and raw TCP, use L3 and L4 policy plus mTLS, with fine-grained checks in the app or a protocol-aware API gateway. Port access alone doesn't establish permission.

Where supported, explicitly allow HTTP routes by method, path, and authenticated source identity; do not treat caller-supplied headers as identity proof
Deny everything else in that namespace and log denied requests
Document protocol exceptions for TCP services that can't use L7
Test that an allowed GET passes while a forbidden POST, wrong identity, and unmeshed caller fail

Done when policies list allowed routes and negative tests prove denial. Where the proxy can't parse traffic, enforce higher up. That's a practical boundary. Work within it.

Harden the control plane and credential lifecycle

Workload traffic attracts attention, but the API server is the richest target in the cloud infrastructure. Cluster-admin access can defeat mesh policy. Include the control plane in zero trust.

Protect the API server with least-privilege RBAC and short-lived credentials. Use an identity provider such as OIDC for human access and appropriately scoped, short-lived credentials for automation instead of shared static kubeconfigs. Restrict kubelet and etcd access to necessary components through firewalls and certificate checks. Audit changes to labels, NetworkPolicy objects, ServiceAccounts, and RoleBindings: these rewrite security boundaries. Test scheduled rotation of client certs and ServiceAccount tokens.

Treat tokens and client certs as ephemeral. Projected volumes and short lifetimes, combined with automatic reloads, let pods adopt new credentials without manual restarts. Year-long tokens have no place here. Revoke and replace any you find.

Give each team and pipeline a Role containing only necessary verbs
Require OIDC, MFA-backed login where possible, short token lifetimes, and privileged-exec auditing
Restrict anonymous access according to the platform's supported configuration, preserving required health checks, and review aggregation-layer permissions
Encrypt etcd backups and test restores without wide-open access

Done when nobody uses cluster-admin daily and audit logs identify policy changes and their authors. Label changes that bypass NetworkPolicy need approval.

Prove enforcement with logs and metrics

If you can't show a blocked attempt, you can't claim you blocked it. Observability makes zero trust a checkable control.

Collect available proxy or network enforcement telemetry alongside Kubernetes API audit events. Confirm which decisions your implementation actually exposes, and use active tests to cover visibility gaps. Watch blocked requests and TLS handshake failures alongside certificate expiry and rotation success. Tightened rules should produce denies that settle as callers fix their paths. No activity can mean policy isn't in the traffic path.

Map TLS termination separately. Mesh TLS commonly ends at a workload proxy; that does not mean the proxy can inspect application-level TLS or that the local application hop is encrypted. Keep application TLS where your threat model requires it, and choose a supported gateway or application layer for authorization when payloads are opaque. Record termination points so ingress encryption is not mistaken for end-to-end protection. Monitor egress too: allowed outbound calls can carry stolen data.

Dashboard blocked attempts, TLS failures, cert age, and rotation errors by namespace
Alert on rejected unauthenticated attempts to protected services and approaching certificate expiry
Retain audits of policy changes, execs, port-forwards, ServiceAccount use, and secret access
Run weekly negative tests and store results with release notes

Test the deny, don't assume it. Positive tests show the app still works. Negative tests show zero trust still works.

Roll out one namespace at a time

Switching a whole cluster to strict zero trust overnight risks an outage and rollback. Start with one critical namespace or application path whose owners and traffic you know.

Use audit or observation-only capabilities where available; otherwise test proposed rules in a representative non-production environment. Fix callers, add narrowly scoped DNS and monitoring allowances, and examine metrics before enforcing with a fast rollback ready. Expand only after positive and negative tests pass for a full release cycle. This matters especially for shared logging and service discovery that everything depends on.

Pick a namespace with cooperative owners and clear traffic
Allow necessary DNS, probes, metrics, and controller flows at the correct enforcement layer; account separately for node-originated image pulls
Require code review for label, policy, ServiceAccount, and RoleBinding changes during rollout
Define rollback steps and on-call ownership before enforcement

Set a rollout gate that spans your normal release cycle and scheduled workloads. Proceed when the first namespace's intended policies hold, required traffic succeeds, and no undocumented emergency exceptions remain. Then choose the next one.

Zero trust in Kubernetes is never finished. Workloads change and services appear each week. Keep testing the deny.