How Tigera Enforces Zero Trust on Kubernetes With Calico

Kubernetes simplifies the deployment of distributed applications, but its networking model introduces security challenges. Pods are often created, replaced, and moved between nodes. Their IP addresses change, services talk across namespaces, and applications usually rely on external APIs or databases.

Traditional security controls based on fixed networks and trusted zones do not fit well here. By default, Kubernetes pods can talk to each other unless network policies block them. If one workload is compromised, an attacker could reach other services in the cluster.

Tigera solves this problem with Calico, its platform for Kubernetes networking, security, and observability. Calico lets teams control how pods, namespaces, hosts, and external networks communicate. The open-source, cloud, and enterprise versions offer different options for managing policies, visibility, and threat defense.

Why Kubernetes strains perimeter security

Perimeter security assumes that systems inside a protected network are treated differently from those outside. In a Kubernetes cluster, this assumption can be risky when communicating with an internal API that talks to a database, a message broker, and a monitoring service. If every workload inside the cluster can reach every other workload, compromising the first application can open several paths for lateral movement.

Zero trust changes the starting assumption. Every connection must match an approved rule, regardless of whether the source and destination are inside the same cluster or namespace. Services receive only the network access required for their role.

This means Kubernetes security is about managing traffic inside the cluster (east-west), not just traffic coming in (north-south). Ingress controls filter incoming traffic, but they do not determine which internal services can communicate with each other once the traffic is inside.

Starting with default deny

Calico works with Kubernetes NetworkPolicy resources and its own advanced policy types. Teams use these policies to set which incoming and outgoing traffic is allowed for certain workloads.

The main zero-trust rule is default deny. Once a workload has an ingress or egress policy, any traffic not clearly allowed is blocked. Calico supports default-deny policies for either a single namespace or the entire cluster.

A blanket deny rule is simple to explain but risky to use without planning. Applications might need DNS, monitoring, authentication, package repositories, or third-party APIs that are not included in the first policy.

Calico Cloud reduces this risk with staged policies and policy previews. A staged policy shows how new rules would affect traffic without actually enforcing them. Teams can review the results, add any missing allow rules, and enforce the policy once they confirm that applications still work as expected.

Applying identity-aware microsegmentation

Static IP rules do not work well for workloads that are often rescheduled. Calico policies can use Kubernetes labels, namespaces, and service accounts to select endpoints instead.

This lets policies follow the application. For example, a rule can allow workloads labeled as frontend to reach a specific API port while blocking them from accessing database workloads. If frontend pods are replaced and get new IP addresses, the policy still works because it uses their labels.

Service accounts add another layer of identity. Calico can match the service account given to a workload or labels on that account. Kubernetes role-based access control can limit who is allowed to assign those labels.

These controls make microsegmentation possible at the workload level. Segments no longer have to match subnets or large network zones. They can be based on application roles, environments, teams, or sensitivity levels.

Calico also offers GlobalNetworkPolicy for rules that need to apply across multiple namespaces. Security teams can use global policies for shared needs, while application teams keep namespaced policies for their services.

Coordinating policy across teams

Kubernetes policy ownership is usually shared. Security teams set organization-wide rules, platform teams manage shared services, and application teams know which service-to-service connections their software needs.

Calico policy tiers set the order in which policies from different groups are evaluated. Higher tiers hold security controls that come first, while lower tiers have platform and application rules. This setup prevents a namespaced policy from overriding a broader restriction.

Policy still needs the same engineering discipline as other production settings. Rules should be version-controlled, reviewed, tested, and moved through deployment stages. Labels and service accounts also need clear ownership. Identity-based rules are less useful if workloads can assign trusted labels freely.

Making network policy visible

A zero-trust policy can fail in two ways. A rule that is too loose may expose more workloads than planned, while a rule that is too strict may block a needed connection.

Network visibility helps teams spot both issues. Calico Open Source includes a flow logs API called Goldmane and the Whisker web console. Whisker shows live, combined flow records that teams can filter by pod, namespace, policy, source, destination, and verdict. The documentation says these observability tools are a tech-preview feature.

Calico Cloud adds service graphs, flow visualization, dashboards, DNS and HTTP logs, alerts, and packet capture. The policy data attached to flow records can show which rule allowed or denied a connection. That context is useful when an application cannot reach a dependency or when a connection appears that was never included in the application design. 

Visibility also helps teams go from watching traffic to enforcing rules. Calico Cloud can suggest policy changes based on current flow data. These suggestions are staged for review, so engineers can compare the proposed rules with the traffic before deciding to enforce them.

Zero trust depends on a maintained policy

Calico gives Kubernetes teams the tools they need for zero-trust networking: default-deny rules, workload-aware selectors, service account controls, global policies, ordered tiers, flow visibility, and commercial threat-defense features.

The real challenge is keeping an accurate list of allowed communications. Application dependencies change, new services show up, and external destinations shift. Policies and identity labels need to keep up.

With Tigera’s approach, enforcement and observability are part of the same workflow. Teams can watch application traffic, set and stage policies, check their effects, enforce approved paths, and investigate anything unusual. This cycle makes zero trust an ongoing process, not just a one-time setup.