What’s New in Calico: Fall 2024 Enhancements for Kubernetes Networking and Security

It’s almost time for KubeCon North America, and we’re excited to share the latest updates in Calico. These updates improve network and runtime security, make it easier to use, and extend Calico’s strong network security and observability for Kubernetes to VMs and hosts that are not part of Kubernetes clusters. Whether you’re managing Kubernetes clusters, transitioning to a new Linux data plane, or seeking a unified network security solution across your Kubernetes and non-Kubernetes workloads on-premises or in the cloud, Calico’s latest enhancements have you covered.

In this blog post, we will cover Calico’s new features in three major categories.

  1. Network Security
    1. Extending network security to hosts and VMs beyond the Kubernetes cluster
    2. Introducing Calico policy tiers and support for Kubernetes AdminNetworkPolicy and BaselineAdminNetworkPolicy
    3. New sidecar deployment for Envoy in Calico: Flexibility for application-layer security
  2. Networking
    1. Adding nftables support to Calico’s pluggable data plane architecture
    2. Extending unified IP address management (IPAM) to LoadBalancer IPs
  3. Runtime Security and more
    1. Improving network threat detection with customizable deep packet inspection
    2. Prioritizing vulnerabilities with exploit metadata and EPSS scores
    3. Reducing false positives in threat detection with specific process exclusions
    4. Providing an option to enable or disable a detector to improve threat detection efficiency

Network Security Enhancements

Network security is increasingly important in the age of artificial intelligence (AI) with the rise in the use of ‌large language models (LLM), AI models and retrieval augmented generation (RAG) frameworks. Also, organizations are moving rapidly to Kubernetes as part of VM migration, yet many still have critical applications and databases running on traditional hosts and virtual machines (VMs) in hybrid on-prem and cloud environments.

This latest release of Calico extends its network security and visibility capabilities to VMs and hosts, empowering teams to leverage a consistent policy framework for workloads running inside and outside of Kubernetes in any cloud or on-premises environment. Calico also introduces deployment flexibility with the choice of the new nftables data plane and a sidecar-based deployment option for Envoy for application layer security. Let’s look at all the new features for network security.

Extending Calico network security beyond Kubernetes clusters to hosts and VMs outside the cluster

As organizations accelerate their adoption of containers and Kubernetes to modernize their infrastructure, certain workloads remain outside Kubernetes environments and cannot be easily containerized. These include systems, databases, and virtual machines (VMs) that continue to play critical roles in business operations. Despite being outside Kubernetes clusters, these workloads are equally vulnerable to network security threats and require robust network protection.

Calico has long been the leader in network security and observability, providing visibility into workload communication, implementing microsegmentation for workload isolation, and defining egress access controls for containerized workloads in the Kubernetes cluster. This latest release allows Calico to secure VMs and hosts outside the Kubernetes cluster, significantly expanding the scope of how it can secure Kubernetes and non-Kubernetes workloads.

By extending Calico’s proven Kubernetes security model to hosts and VMs, Calico simplifies network security management, ensuring a consistent security posture across your entire infrastructure while providing a single management plane for network security across cloud and datacenters.

Calico also generates and aggregates flow logs for VMs and hosts running outside of Kubernetes. Just like the flow logs generated on Kubernetes cluster nodes, these logs are routed to log stores using FluentD or stored in the included EFK stack (Elastic, FluentD, Kibana).

With the ability to generate, correlate and aggregate flow logs for both Kubernetes and non-Kubernetes workloads, Calico offers consistent security and visibility across your entire infrastructure.

Diagram showing Calico's network policy unifying Kubernetes and non-Kubernetes workload flow log aggregation
Figure 1: Extending Calico network security to VMs and Hosts outside Kubernetes cluster

In this tech-preview release, Calico provides rpm packages for easy installation on RHEL 8 hosts and VMs. Future updates will extend support to additional operating systems, ensuring broader compatibility and streamlined deployment across diverse environments.

Calico Policy tiers and support for AdminNetworkPolicies and BaselineAdminNetworkPolicies

As Kubernetes adoption continues to grow, organizations face increasing challenges in managing and enforcing network policies across multiple teams. Developers often create policies to secure specific workloads, but administrators require cluster-wide security controls that cannot be overridden. Without proper policy prioritization, critical security rules may not always be enforced, leaving Kubernetes environments vulnerable. Moreover, the absence of a defined policy hierarchy can cause operational inefficiencies, as security, platform, and development teams struggle to align their efforts.

Calico OSS 3.29 adds support for AdminNetworkPolicies and upcoming release will add support for BaselineAdminNetworkPolicies, based on two new APIs introduced by the Kubernetes network policy API subgroup and introduces Calico Policy Tiers to provide a more granular priority order in which policies are evaluated as determined by security, platform, application development teams.

The AdminNetworkPolicy helps administrators set strict security rules for the cluster, i.e. a developer cannot override these rules.

The BaselineAdminNetworkPolicy allows administrators to set baseline security rules that can be overridden by developer NetworkPolicies if needed. The canonical use case for these policies is implementing a default deny for the cluster. Any flow in the cluster will be denied unless an AdminNetworkPolicy, CalicoNetworkPolicy, or KubernetesNetworkPolicy explicitly authorizes that flow.

Diagram showing NetworkPolicy priority: Admin, Developer, then Baseline Admin policies.  Lower priority policies override
Figure 2: Calico OSS 3.29 AdminNetworkPolicy and BaselineAdminNetworkPolicy support

Calico Policy Tiers

Calico OSS 3.29 also introduces Calico policy tiers to offer even more control over the order in which all network policies are evaluated and ensure that critical policies are enforced at the right priority level. Calico policy tiers are tied to Kubernetes RBAC (Role-Based Access Control), enabling organizations to delegate policy management within specific tiers to different teams or stakeholders, thus accelerating shift-left security and operational efficiency.

A Calico policy tier is a hierarchical group of network policies that are ordered by priority. Tiers are used to define the order in which network policies are evaluated, with higher tiers evaluated first. Let’s take an example in Figure 3:

Diagram showing Calico policy tiers: Security, Platform, Application, and default, ordered by evaluation priority
Figure 3: Calico OSS 3.29 Policy Tiers

As shown in figure 3, security, platform, and application(s) have their own policy tier with a clear hierarchy of policy processing.

  • Security tier: This tier contains a set of policies defined by the security teams to implement high-level security guardrails for the cluster.
  • Platform tier: This tier contains a set of policies defined by the platform team to implement security controls for platform components such as kube-dns and ingress.
  • Application tier: This tier contains a set of policies defined by the application team to implement coarse-grained security policies for namespaces.
    The traffic flow can be defined for each tier as following:

Diagram showing security tiers: Security, Platform, and Application, illustrating policy implementation flow and control

Calico policy tiers have been a foundational feature of Calico’s commercial offerings, providing a platform to implement microsegmentation, egress access control and shift left security. By introducing Calico policy tiers in Calico Open Source we bring this powerful capability combined with NetworkAdminPolicy and BaselineNetworkAdminPolicy to the open source users, making it easier for Kubernetes platform teams to manage cluster security. To learn more about which Calico edition is right for you, visit the product comparison page.

Calico policy tiers in open source: UI showing policy tiers like security, platform, namespace-isolation, app-catfacts, and
Figure 4: Calico Cloud: Policy dashboard to manage policies and tiers

New Sidecar Deployment for Envoy in Calico: Flexibility for Application-Layer Security

Organizations deploying service mesh architectures and application-layer security often rely on Envoy as a core component. Depending on the architecture, Envoy can be deployed as a sidecar for individual services or as a DaemonSet across nodes. Each deployment method offers distinct advantages and is chosen based on specific organizational requirements for networking, security, and operations.

Both the sidecar and DaemonSet approaches for Envoy deployment have benefits and drawbacks, forcing organizations to make trade-offs depending on their priorities:

  • DaemonSet Deployments: Organizations favoring simplified operations, node-level visibility, and resource efficiency prefer the DaemonSet model. This approach reduces overhead, but it comes at the cost of losing granular control over individual services or pods. Additionally, DaemonSet deployments can limit integration with other sidecar-based infrastructure services like Istio or Linkerd.
  • Sidecar Deployments: For organizations needing service-specific controls, logging, monitoring, traffic routing, and tighter security policies, the sidecar model is more suitable. This approach allows the configuration of service-specific Envoy sidecars based on infrastructure needs and is crucial for environments with service meshes that require sidecars (e.g., Istio with mTLS). However, sidecar deployments also increase CPU and memory overhead for each pod, which can lead to higher costs and scaling challenges.

With this release, Calico introduces sidecar deployment support for Envoy, in addition to the existing DaemonSet model. This new feature gives organizations the flexibility to choose the approach that best suits their networking and security needs. Whether the granular control provided by the sidecar model is required or the operational simplicity and efficiency of the DaemonSet is preferred, Calico enables you to select the right deployment model based on your environment.

By supporting both sidecar and DaemonSet deployment models for Envoy, Calico allows organizations to:

  • Adapt to infrastructure needs: Choose between granular control with sidecars or resource efficiency with DaemonSets.
  • Full compatibility: Ensure greater compatibility with certain Kubernetes platforms, such as GKE, AKS, EKS, and WireGuard.
  • Optimize performance: Strike the right balance between performance and control, tailoring your Kubernetes environment to meet specific security and networking requirements.

Diagram of pods with sidecar containers, showing ingress/egress traffic, and Kubernetes platform logos

Networking Enhancements

Support for the New nftables data plane

As Linux distributions like RHEL 9 and Debian move from iptables to nftables, Calico Open Source introduces native support for nftables to ensure Kubernetes users can seamlessly transition their Calico CNI, IPAM and network policies to these new Linux distributions with default nftables dataplanes.

Thanks to Calico’s pluggable data plane architecture, we can seamlessly add support for newer dataplanes, offering users the flexibility to choose the best solution for their specific needs. Today, Calico supports multiple dataplanes, including eBPF, Linux nftables, Linux iptables, Windows HNS, and VPP, giving users a range of options for their environments.

Calico cat icons representing different dataplanes: nftables/iptables, eBPF, Windows HNS, and VPP, illustrating Calico's

Unified IP Address Management (IPAM) Supports LoadBalancer IPs

Managing IP addresses for Kubernetes workloads and services can be complex, especially with separate IPAM solutions for LoadBalancer IPs and pods. Calico now extends its IPAM capabilities to manage LoadBalancer IPs, providing a unified solution for IP management across all Kubernetes resources.

Kubernetes operators often face challenges in managing IP addresses for external services using load balancers, such as MetalLB, to route traffic to services inside the cluster. Currently, they rely on separate IP management solutions for load balancer IPs, while using a different system for managing pod and workload IPs. This fragmented approach leads to unnecessary complexity, potential misconfigurations, and difficulties in ensuring consistent IP management across their environments.

Calico now offers a unified solution by extending its IP Address Management (IPAM) capabilities to also manage LoadBalancer IPs. With this update, platform teams can use a single IPAM solution to manage IP addresses for all resources—whether they are pods, workloads, or load balancers. This seamless integration works with popular load balancers like MetalLB and those provided by major cloud platforms such as AWS, Azure, and Google Cloud.

A unified IP management approach reduces complexity, minimizes the risk of misconfigurations, and supports large-scale, dynamic environments.

Runtime Security and More

The new release of Calico also includes essential capabilities for security teams. Today, there is a critical need to simplify security monitoring. Security teams are overwhelmed with the number of security events and false positives, and need solutions that help them become more efficient in their roles. Tigera has enhanced Calico’s runtime security capabilities, including fine-tuning the detectors to eliminate noise and make the detection more targeted.

Customizable Deep Packet Inspection (DPI)

Calico’s Deep Packet Inspection (DPI) significantly enhances Kubernetes network security by detecting threats including APTs and zero-day exploits hidden within packet contents. This enables organizations to protect their Kubernetes cluster more effectively against evolving network-based security threats.

Calico’s DPI has leveraged snort community rules to identify potential threats based on pre-configured rules in the platform that detect specific signatures within packets. These rules flag traffic automatically. They will be tagged as global alerts under alerts in Calico’s activity panel.

With this release, Calico now provides security administrators with the ability to configure and customize snort rules used in DPI. This new feature gives users greater control over the rules that are evaluated within their deployment, allowing them to selectively enable or tune rules based on their specific security needs. By configuring DPI rules, users can phase their deployment of network-based threat detection more effectively. Key new capabilities include:

  • Modifying the built-in community Snort rules provided by Calico to better suit their environment.
  • Leveraging custom snort rules, including those available through paid subscriptions, to enhance threat detection.
  • Receiving automatic updates to Tigera-provided Snort rules with each new Calico release, ensuring users stay up-to-date with the latest threat intelligence.

Calico's Snort integration: UI showing suspicious traffic flagged by a Snort rule, illustrating threat detection

By giving users more flexibility and control over DPI rules, Calico enhances network security in Kubernetes environments, allowing for more tailored and efficient threat detection.

Prioritize Vulnerabilities with Exploit Metadata and EPSS Scores

Organizations are often overwhelmed by the sheer volume of vulnerabilities they detect in their containerized workloads. While shift-left helps surface issues early, the challenge lies in the context: without understanding the exploitability of a vulnerability or probability of exploitation, remediation teams struggle to prioritize which vulnerabilities to address first. This lack of prioritization can have serious implications, including slowing down the pace of innovation or introducing security risks by pushing high-risk code into production.

Calico now integrates the CISA Known Exploited Vulnerabilities (KEV) Catalog and Exploit Prediction Scoring System (EPSS) to help teams prioritize vulnerabilities based on their exploitability. This added context enables security teams to focus remediation efforts on the vulnerabilities most likely to be exploited.

Screenshot of Calico's 'All Scanned Images' page, highlighting EPSS Score and Percentile filters for vulnerability

By pulling in information about available exploits for vulnerabilities and EPSS scores, Calico empowers organizations to move beyond traditional severity-based vulnerability prioritization and instead focus on real-world risk. This second layer of prioritization allows teams to:

  • Reduce the noise: Focus on the vulnerabilities that are most likely to be exploited or have active exploits.
  • Allocate resources efficiently: With exploit data and predictive insights, DevOps and security teams can prioritize their efforts where they will have the most significant impact.
  • Improve security outcomes: By addressing the most likely and dangerous vulnerabilities first, teams can reduce the risk of exploitation and improve the overall security of their containerized workloads in Kubernetes.

Vulnerability scan results showing critical and high severity vulnerabilities to prioritize

Reduce False Positives in Threat Detection with Process Exceptions

As organizations adopt containerized environments, threat detection becomes critical to ensuring security. However, in many cases, false positives generated by trusted processes and infrastructure tools create unnecessary noise and slow down remediation efforts. These trusted processes often have privileged access and actions as part of their normal operation, which can trigger threat detection mechanisms despite not posing any real threat.

For example, in container-based environments, many tools and infrastructure components—such as the Dynatrace OneAgent, certain Azure Kubernetes Service (AKS) agents, and the kured process—require elevated privileges or specific actions to function properly. These actions can trigger threat detection alerts, creating false positives. For security teams, this leads to frustration and inefficiency, as time is wasted investigating alerts that do not represent real threats.

To address this challenge, Calico Cloud is introducing a process exception feature that allows users to add specific processes to an exclusion list for each threat detector. By doing so, trusted processes can be excluded from threat detection, significantly reducing the number of false positives.

kubectl apply -f - <<EOF
apiVersion: operator.tigera.io/v1
kind: RuntimeSecurity
metadata:
name: default
spec:
runtimeExceptionList:
- matching: Exact
processInvocation: "runc init"
namespace: default
- matching: Regex
processInvocation: "b(shred|rm|mv).*((bash|ash|zsh|fish|fish_read)_history|history)b"
EOF

The new process exclusion feature in Calico Cloud helps organizations reduce the burden of false positives, improving the accuracy and efficiency of container-based threat detection. By giving users more control over which processes are flagged for detection, this feature enables teams to focus their efforts where they matter most—on real threats—while streamlining the remediation process for faster, more effective security operations.

Enable or Disable a Detector to Improve Threat Detection Efficiency

Efficiently detecting and responding to container-based security events is critical, and customizing container threat detection can further help security teams customize their application security according to their requirements.

Calico Cloud now allows users to visualize and selectively enable types of detectors in their clusters, mapped to Mitre framework tactics of persistence, privilege-escalation, access, execution, defense-evasion, impact, and discovery. It improves the accuracy and efficiency of detecting and responding to security events related to container-based threats for their specific environment.

Calico Cloud's Detector Settings screen, showing detector types mapped to MITRE ATT&CK tactics, with enable/disable toggles

For security teams, this improved detection capability enhances the organization’s security by customizing threat detection to the environment, thus optimizing resource use. Security teams can benefit from the ability to tune threat detection to their specific needs, improving the accuracy and efficiency of detecting security events and ensuring that security measures are both effective and tailored to these unique requirements of their environment. It also allows teams to phase their threat detection deployment as they identify sources of false positives and tune the detector to their environment.

Screenshot of Container Threat Detection settings, showing customizable threat detection rules and severity levels

It’s a wrap for this release. Calico and Tigera team have been working hard to get new and exciting capabilities to Calico Open Source Users, help infrastructure teams implement network security across VMs and Bare Metal for non-Kubernetes clusters, and strengthening runtime security portfolio by improving signal-to-noise ratio for security teams to address most critical security threats inside and outside their environment.

Check out these new features by signing up for a free trial of Calico Cloud

Join our mailing list

Get updates on blog posts, workshops, certification programs, new releases, and more!

X