Securing your Kubernetes cluster with Calico

As organizations increasingly adopt Kubernetes, securing communication between pods has become a fundamental requirement for maintaining a reliable and resilient infrastructure. Kubernetes provides a basic implementation of Network Policies to manage traffic between pods and services. While this is sufficient for simple use cases, production-grade environments typically require more advanced and fine-grained security controls.

This article examines how Calico builds upon Kubernetes’ native capabilities, offering extended features that support the transition from basic traffic management to a comprehensive security model.

Kubernetes Network Policy rules

A useful way to think about Kubernetes networking is through analogy. Consider a Kubernetes cluster as a country made up of multiple cities (namespaces). Each city contains multiple buildings (pods), connected by roads that enable travel both within and between cities.

• Network Policies act as traffic regulations posted at specific buildings. They define who can enter, who can leave, and through which routes (ports).
• Ingress rules function like border checkpoints, controlling external visitors entering specific buildings (pods).
• Egress rules serve as exit controls, governing traffic leaving a building, whether directed toward other cities (namespaces) or external destinations such as the internet.

With this analogy in mind, it is useful to move to the formal concepts that will be referenced throughout this article.

Network Policy

• A Kubernetes resource that defines allow rules for selected pods, based on IP addresses, ports, and protocols.
• By default, pods can communicate freely with any other endpoint. Once a policy applies to a pod, all traffic is denied unless explicitly allowed.
• Network policies are additive. Each rule specifies which pods, namespaces, or IP ranges are permitted, and through which ports and protocols.

Ingress and egress in Network Policies

• Ingress rules control traffic entering pods.
• Egress rules control traffic leaving pods.
• Both are always defined from the perspective of the pods targeted by the network policy.

A practical example

With the key concepts established, it is helpful to examine how the default Kubernetes Network Policy operates in practice, including its possibilities and limitations.

Consider a typical application architecture in which Network Policies are applied to control pod-to-pod communication across different namespaces.

In this example:

• End users can access only designated pods in the frontend namespace. This restriction is enforced by a default deny-all policy applied across all three namespaces.
• Pods in the backend namespace accept incoming connections exclusively from the frontend namespace. Outgoing connections from the backend are permitted only toward the db namespace.
• Pods in the db namespace are fully isolated, accepting incoming connections solely from pods within the backend namespace.

This setup illustrates how Network Policies can enforce controlled and predictable traffic flows, ensuring that each component of the application communicates only with the intended services.

Vanilla Network Policy limitations

Even though the setup described earlier may be sufficient for basic requirements, in production environments (where services are more sensitive and security demands are higher) the limitations of the vanilla Network Policy become evident. The key ones are:

• Missing cluster-wide policy: Network policies are namespace-scoped. As in the previous example, the default deny-all policy had to be deployed in each namespace. This increases complexity when aiming for a standardized, cluster-wide approach.
• Pod-centric, namespaced: Policies target pods, not Services. It is not possible to define a rule such as “allow to Service X.” In the earlier example, all policies were applied to pods selected by labels.
• Rudimentary control of external traffic: There is no DNS-based rule for incoming traffic (for example, allowing connections from example.com). Only specific IPs or CIDR ranges can be used, which breaks when public or dynamic IPs change.
• No explicit deny rules or priority: All policies are additive allow lists. There is no mechanism to apply deny rules or set priorities that override existing allows.
• No encryption or observability: Network Policies do not provide mTLS or IPsec, meaning there is no built-in encryption between network devices (pods, endpoints, etc.).
• Limited decision logging: Network Policies lack logging support for applied rules or decisions, making it difficult to diagnose or resolve communication issues.

Depending on application requirements, these limitations may prove to be a critical barrier. One possible solution is the Calico project, developed by Tigera.

Calico: purpose & role

According to Tigera, Calico is a single platform for Kubernetes networking, network security, and observability, supporting any Kubernetes distribution in the cloud, on-premises, or at the edge.

Whether an organization is just starting with Kubernetes or managing a mature, multi-node cluster, Calico can address most network requirements an application or infrastructure may demand.

As the saying goes, “a picture is worth a thousand words.” In this context, a landscape overview of Calico provides the most useful perspective.

As shown in the landscape above, Calico has several notable characteristics:

• Cross-platform availability: Calico supports both Windows and Linux containers.
• Flexible deployment options: Whether the application runs in a virtual machine, on bare metal, or in a container, Calico operates consistently across environments.
• Plug-and-play integration: Application components do not require modification. Network security can be fully managed by the platform or security team.
• High-performance data planes: Calico offers a choice between eBPF or iptables on Linux, combined with native routing to improve performance and platform compatibility.
• Multiple delivery models: Calico can be used in different ways: as part of a self-managed Kubernetes distribution or as a SaaS option available in Azure, AWS, or Google Cloud.

What makes Calico different

Having outlined Calico’s purpose, we can now return to the earlier example and examine the limitations identified with the default Kubernetes Network Policy.

Calico extends the standard Kubernetes Network Policy with additional capabilities that provide greater control over cluster traffic. Below, each of the previously noted limitations is revisited, along with the way Calico addresses them:

Global Network Policy

Unlike Kubernetes Network Policy, which is limited to a single namespace, Calico’s Global Network Policy can apply rules across all namespaces or target specific ones. This enables consistent, cluster-wide security enforcement.

For example, a single default deny-all policy can be written to cover the entire cluster. This aligns with the Zero Trust Network model, in which all traffic is initially denied and access is explicitly granted only as required. More details here.

Targeting Kubernetes Services

In contrast to the vanilla Network Policy, which only supports label selectors, Calico allows policies to target a specific Kubernetes Service within a namespace. This makes it possible, for instance, to define access from the frontend namespace directly to the backend service. More details here.

DNS/FQDN-based egress rules

Calico supports DNS- or FQDN-based egress rules, making it possible to allow traffic to domain names such as api.example.com. This provides a level of control not available with standard Kubernetes policies and is particularly valuable for managing internet access. DNS-based deny rules are still not supported. More details here.

Policy tiers

Calico introduces policy tiers, such as security, platform, and application. These tiers establish order and priority in rule enforcement. For example, a security team can manage policies in a top-level tier that always applies before application-specific rules.

By comparison, vanilla Network Policies only allow additive rules, all applied at the same level.

Advanced security features

Calico adds several advanced capabilities:

• Explicit deny rules, enabling more precise control over blocked traffic.
• Encryption for data in transit, using WireGuard integration to secure communication between pods and nodes.

See more on how to enable inter-node, in-cluster encryption.

Observability

With vanilla network policies, visibility into cluster communication is limited, making troubleshooting difficult.

Calico provides extensive observability features, including DNS logs, flow logs, and Layer 7 logs, allowing administrators to monitor, validate, and debug policies effectively. Even in the open-source version, a dashboard is available through Calico Whisker, which presents real-time network activity streams derived from flow logs.

Key integrations: eBPF, WireGuard, and Envoy

Calico integrates with several technologies to strengthen security, improve performance, and increase visibility within Kubernetes clusters:

• eBPF moves networking and security logic directly into the Linux kernel, enabling higher performance and detailed packet flow visibility. More about here.
• WireGuard provides lightweight, fast encryption for pod-to-pod and pod-to-service communication. More about here.
• Envoy works alongside Calico to apply and enforce service-to-service security policies, securing applications at both the network and application layers. More about here.

Together, these integrations demonstrate how Calico extends beyond basic network policies, evolving into a comprehensive networking and security platform for Kubernetes. They enhance performance, provide encryption, and increase transparency into network traffic.

However, these are not the only features Calico offers, nor is there a single edition available. The next section explores the different production editions of Calico and their intended use cases.

Calico: Open Source vs. Cloud

When selecting Calico, there are two primary editions to consider: Calico Open Source and Calico Cloud. Both are feature-rich, but they address different requirements depending on an organization’s stage in its Kubernetes adoption.

Calico Open Source – DIY control

For organizations that prefer to manage their own infrastructure, the open-source edition of Calico provides a strong foundation for Kubernetes networking and security. Key characteristics include:

• Full support for Kubernetes Network Policies
• Flexibility to adapt and extend according to cluster needs
• An active community for support and collaboration
• Free of charge, making it attractive for cost-sensitive environments

The trade-off is that the open-source edition requires in-house management of upgrades, monitoring, and troubleshooting. This can result in longer time-to-market for advanced features and greater maintenance effort, as the organization is responsible for ensuring operational stability.

Example: Calico Whisker
The open-source edition also includes observability capabilities. For instance, Calico Whisker provides a lightweight dashboard offering real-time visibility into network flows.

Calico Cloud – Managed simplicity

Calico Cloud builds on the open-source foundation and provides a managed service available across major cloud platforms such as Azure, AWS, and Google Cloud.

In addition to the capabilities of the open-source edition, Calico Cloud offers:

• A single pane of control for managing multiple clusters from one interface
• Real-time traffic flow visualization
• Built-in compliance and audit tools to meet regulatory requirements without additional engineering effort
• Advanced security features such as intrusion detection, zero-trust enforcement, and more

This edition requires a subscription cost, but in return it provides faster time-to-market, reduced maintenance overhead, and enhanced security and observability.

Example: Calico Cloud Dashboard
The example below illustrates the advanced observability features available in Calico Cloud.

Finally, the two editions can also be compared from a more strategic perspective, focusing on broader operational criteria:

For a complete list of available features, check the official feature comparison matrix.

Conclusion

Vanilla Network Policies represent a useful starting point. However, real-world Kubernetes environments typically require stronger measures to meet production security needs. Calico extends the native capabilities, delivering a more comprehensive security framework that is suited for production use.

By integrating with technologies such as eBPF, WireGuard, and Envoy, Calico further enhances performance, provides encryption, and strengthens service-level security.