Every day, the drumbeat to adopt Zero Trust in tech infrastructure amplifies. Like any cybersecurity buzzword, Zero Trust is both more and less than it seems. As more, it holds an enduring concept and construct for better cloud-native security. As less, it doesn’t require new technology or tools – rather, Zero Trust is a series of implementation steps.

The seven rules below account for how cloud native radically shifts ways applications are built, operated, and delivered to end users. Caveat: These rules assume your Zero Trust is for containers orchestrated by Kubernetes, the de facto container management standard and most-developed ecosystem for managing containers at scale.

Let’s break down a zero-stress path to Zero Trust for Kubernetes.

1. Avoid Adding Complexity to Kubernetes

You don’t need new, fancy applications to do Zero Trust right. Everything necessary is widely available as open source Kubernetes tools and common API management, load balancing, and application security solutions. Zero Trust is an evolution of security shifts you’re likely already implementing to handle today’s realities of distributed teams and users, API connectivity, and cloud-based application topologies.

2. Add Minimal Overhead to Developers and End Users

Don’t force developers or end users to radically alter existing workflows. Design your Zero Trust to work in the background. Keep certificate rotations transparent. Implementing passive multi-factor authentication (MFA) checks, like a USB-key plugged into a laptop, simplifies things. If you need to interrupt users, do it mindfully. A simple identify confirmation request on an authentication application is not major – users are already used to this with consumer applications. With Zero Trust, you could make requests more frequent. This might seem like a hassle but, if it resolves in a few seconds, then the disruption is sustainable, beneficial, and worth the effort.

3. Apply to the Data and Control Planes

This is critical. Not applying Zero Trust rules in both planes creates weak, exploitable links in the chain of trust. Control plane rules lock down policies and ensure attackers cannot generate policy and logic changes, which enable horizontal, traversal, or other secondary attacks. Data plane rules guard against brute force and lower-level attacks that overwhelm or perforate perimeter security (e.g., malformed queries or requests and DDoS). If you already have a Zero Trust mentality, you’ve likely added many rules applicable to Zero Trust at the data plane. At the control plane, Zero Trust is less likely to have been applied because (big surprise) admins enjoy giving themselves expansive privileges. Be aware of your two planes and how their interaction points can be secured with Zero Trust principles.

4. Apply to East‑West and North‑South Traffic

This evokes standard perimeter security with added verification frequency and closer scrutiny on traffic origin, duration, and type. Many organizations erroneously run Kubernetes without strong security for internal service-to-service (east-west) traffic. In Kubernetes, east-west traffic is the majority – most applications communicate via APIs and adopt microservice or small application paradigms. Attackers know that the volume of Kubernetes cluster traffic dwarfs external traffic flows. They travel via east-west pathways, taking advantage of the architecture’s soft underbelly, actively seeking to gain unauthorized Ingress-egress (north-south) access. Applying Zero Trust to east-west traffic blocks many of these attacks.

5. Use an Ingress Controller and Service Mesh

Ingress controllers and service meshes work together to make Zero Trust effective in Kubernetes. Ingress controllers manage north-south traffic and are the logical point for continuous authentication of external APIs interacting with internal services. Service meshes orchestrate and synchronize internal microservice interactions, and are the logical location for automated certificate rotation for internal services. Lacking either makes it difficult to apply Zero Trust in the previous rule.

6. Integrate the Ingress Controller and Service Mesh

Your Ingress controller and service mesh must communicate. This ensures effective Zero Trust and smooth, consistent operation of your applications and microservices. Ideally, your Ingress controller and service mesh share a common set of traffic policies. In advanced scenarios, teams responsible for implementing Zero Trust policies and traffic rules set up “if-then” chains to make Zero Trust more adaptive and less onerous, increasing scrutiny when indicators of compromise (IOCs) are detected.

7. Automate Proper Handling of Certificates

Certificate management is a common complaint for DevOps, security, and SRE teams establishing Zero Trust strategies. If your Kubernetes architecture has dozens of microservices, every service can only promptly receive properly configured and validated certificates if the process is automated. Manual certification becomes unworkable. Design certificate authentication and acceptance policies for near-continuous checking (10 or 15 minute intervals). Yes, this differs both in practice and principle than monthly or bi-monthly certification rotation, where an admin pushes new certificates to all systems. Fortunately, certification is well-solved in Kubernetes and several paths exist for adding automated certificate handling.

Start Your Zero Trust Journey Today

Zero Trust is present and pressing. Just this year, the U.S. Government pushed federal agencies to adopt Zero Trust practices. Remember: This is a journey, not a destination. The seven rules above are a starting point. They’ll need modification as technology evolves (for example, automated certificate handling could someday be a default module in container orchestration). Today, with these rules, teams can begin mapping out a strategy for Zero Trust in Kubernetes.

CTA: Let your Zero Trust voyage begin. Visit the F5 NGINX Zero Trust solution page to learn how NGINX can help improve your security posture.