DEV Community: Alister Baroi

Anthropic Mythos Broke Firefox: 271 zero-day vulnerabilities

Alister Baroi — Thu, 23 Apr 2026 23:12:05 +0000

271 zero-day vulnerabilities. One AI model. One Firefox release. And that's just one of four stories worth your attention this fortnight.

If you run engineering, security, or AI at your company, this article will give you a clear message: AI is no longer something your team uses. It's something your team (and your attackers) deploys. Here are the four moves that matter, and the numbers behind each.

1. Mythos found 271 zero-day vulnerabilities in Firefox 150

On April 22, Mozilla shipped Firefox 150 with patches for 271 security vulnerabilities, all identified by Anthropic's unreleased Mythos model during what Mozilla calls its initial evaluation. For context: across all of 2025, Mozilla patched roughly 73 high-severity Firefox bugs. Mythos delivered almost 4× that count in one evaluation window.

Mythos is distributed under Anthropic's restricted Project Glasswing programme: not a public model, and not available via API.
Firefox 150's security advisory lists 41 CVEs; three of those CVEs are memory-safety roll-ups that bundle many of the 271 individual defects.
The most serious finds were use-after-free bugs in the DOM and WebRTC, the same bug class that has driven browser exploitation for two decades.
Mozilla's caveat (worth quoting verbatim): Mythos did not find any category of bug that an elite human researcher could not have found. The gain is scale and speed, not new capability.

"A gap between machine-discoverable and human-discoverable bugs favors the attacker, who can concentrate many months of costly human effort to find a single bug. Closing this gap erodes the attacker's long-term advantage by making all discoveries cheap." — Mozilla, on the shift in attacker/defender economics.

If Anthropic can hand Mozilla 271 real bugs in a single evaluation, assume your own vendors (and your adversaries) are running similar passes on your stack. The question to ask this quarter is no longer "do we use AI in our security review?" — it is "which of our vendors do, and what does our threat model look like if attackers scale this before we do?"

2. Anthropic launched Claude Design

On April 17, Anthropic released Claude Design, a new Anthropic Labs product built on Claude Opus 4.7. It turns Claude into a design tool that produces real deliverables: prototypes, slide decks, one-pagers, marketing collateral.

Reads your codebase and existing design files to apply brand rules automatically.
Accepts 5+ input formats: text prompts, images, DOCX, PPTX, XLSX.
Exports to Canva, PDF, PPTX, HTML, or a shareable internal URL.
Hands off to Claude Code when a prototype needs real implementation.
Available in research preview across 4 subscription tiers: Pro, Max, Team, Enterprise.
Datadog's quantified claim: prototyping that took one week of back-and-forth now happens in one conversation.

This is Anthropic stepping out of "model behind an API" and into "end-user product", competing directly with Figma, Canva, and the slide-building half of Microsoft 365. If your product organisation still treats model vendors as neutral infrastructure, that assumption has a shorter shelf life than your next budget cycle. The vendor now competes with some of your tooling.

3. Google open-sourced DESIGN.md

Google Labs released a draft open-source specification called DESIGN.md, a format that describes design systems in a way AI agents can read, reason about, and validate against. It shipped alongside Stitch (Google's AI UI tool), but the format itself is platform-agnostic and hosted on GitHub.

Encodes design intent so AI agents stop guessing, "agents can know exactly what a color is for".
Includes built-in WCAG accessibility validation.
Portable across any tool or platform, not locked to Stitch.
Released as a draft spec, open to contribution.

Watch the format, not the tool. Markdown files that AI agents read for persistent context — CLAUDE.md, AGENTS.md, README.md, and now DESIGN.md — are becoming the lingua franca of AI-native workflows. The standard here is being set in public, right now. Whichever spec wins become the default your engineering teams (and their AI copilots) work against for the next decade. API.md, SECURITY.md, and ONBOARDING.md are the obvious next chapters. If you have a design system or a platform team, this is a draft you want an opinion on.

4. OpenAI is quietly building "Hermes" — always-on agents inside ChatGPT

Leaked internal screenshots, surfaced by TestingCatalog between April 6–21, show OpenAI actively developing a platform codenamed Hermes. It adds persistent, 24/7 agents to ChatGPT — agents that run even when you are not at the keyboard.

Custom workflows and skill assembly.
Task scheduling and event-triggered actions.
External messaging connectors: agents can reach users outside ChatGPT.
Role-based templates: leaked screenshots show CTO and CPO archetypes.
Multi-agent orchestration, integrated with OpenAI's existing Workflows builder.
Status: internal beta. No release date confirmed. Unofficial: treat as leak, not announcement.

Signal for engineering leaders: If Hermes ships in the form shown, ChatGPT stops being a chat interface and becomes a runtime for autonomous systems, a direct competitor to Salesforce Agentforce, Microsoft Copilot Studio, and every agent startup built on top of the OpenAI API. Those startups are then competing with their own platform provider, using agent patterns their provider can see in aggregate across hundreds of millions of users. If your 2026 roadmap includes an AI agent strategy built on vendor APIs, this is the risk line item you want in your Q3 review.

The Thread

Four announcements, two weeks, one pattern. AI this fortnight was not about bigger models or cleaner benchmarks. It was about AI doing the work — finding real zero-days in shipped software, producing design artifacts that replace a week of iteration, standardizing how agents read intent, and (in OpenAI's case) running as always-on infrastructure your teams have not yet budgeted for.

The message for leaders is simple: the operational reality of AI is moving faster than most roadmaps were written to handle.

KubeVirt Networking: How to Preserve VM IP Addresses During Migration

Alister Baroi — Tue, 21 Apr 2026 20:55:58 +0000

Organisations are re-evaluating their VM infrastructure. The economics have shifted, the tooling has matured, and the case for running two separate platforms, one for containers, one for VMs, is getting harder to justify. Platform teams that spent years managing hypervisor infrastructure are being asked to consolidate, and most are landing on the same answer: Kubernetes.

KubeVirt makes running VMs on Kubernetes possible. But KubeVirt networking – what happens to a VM’s IP address, VLAN, and security posture when it lands in a cluster – is where most migration plans hit a wall. The reasons go beyond cost:

Most enterprises already run Kubernetes. Containers are already there. Adding VMs to the same platform consolidates tooling, lifecycle management, networking models, and security policy into a single operational model.
Two platforms means double the overhead. Separate infrastructure means separate upgrade cycles, separate monitoring, separate network configuration, and separate on-call runbooks. Platform consolidation has direct operational value.
Kubernetes is mature enough. KubeVirt has reached the point where it’s a viable production choice for enterprise VM workloads.

The decision to migrate is being made. The question is how to do it without causing chaos.

Introducing KubeVirt

KubeVirt extends the Kubernetes API with new custom resource types: VirtualMachine and VirtualMachineInstance. These make VMs first-class Kubernetes objects — scheduled, managed, and observable through the same tools and APIs as containers.

A VM running in KubeVirt runs inside a virt-launcher pod. Kubernetes schedules that pod to a node with available resources, the same way it schedules any other workload. The VM gets CPU and memory from the node. It doesn’t know it moved.

That’s the point: from the VM’s perspective, KubeVirt is invisible. The operating system keeps running. The application keeps running.

KubeVirt virt-launcher pods in Kubernetes

The network is a different story

When you migrate a VM, three things have to follow: compute, storage, and network. Compute and storage are properties of the VM itself — self-contained. KubeVirt handles them by giving the VM a new host and a new storage backend. The VM doesn’t notice.

Dependencies of VM migrations

The network is different. The network isn’t a property of the VM. It’s a property of the VM’s relationship to everything else in the infrastructure.

A VM’s compute dependency is between the VM and its host. A VM’s storage dependency is between the VM and a storage backend. But a VM’s network dependency is between the VM and every other system that knows how to reach it.

That distinction is why networking is where VM migrations stall. This isn’t theoretical. KubeVirt’s own issue tracker documents the problem directly: a user reported their VM’s IP changing after live migration, and a project maintainer confirmed: “Sticky IPs is not implemented.” The network identity doesn’t follow the VM by default.

Lift-and-Shift VMs to Kubernetes with Calico L2 Bridge Networks

Why default KubeVirt networking breaks VM migrations

When a VM lands in Kubernetes using default pod networking:

It receives a new IP address from the cluster’s pod CIDR. A range that exists only inside the cluster
The original VLAN doesn’t exist inside the cluster. Kubernetes has no native VLAN concept in default networking
Pod IPs are only meaningful inside the cluster. The upstream network has no direct visibility into them

From the perspective of every system that previously knew the VM by its address, the VM has disappeared. Something with an unfamiliar IP has appeared inside a cluster that the upstream infrastructure can’t see into.

A VM’s IP address accumulates dependencies over time. By the time you’re migrating it, that IP is embedded in:

Firewall rules — security teams wrote rules allowing or denying traffic to that specific address.
DNS records — the hostname resolves to that IP.
DHCP configuration — the IP is reserved for that VM’s MAC address.
Monitoring and alerting — observability tools are configured to watch that address.
Load balancer backends — upstream load balancers route traffic to that IP.
Application configuration files — other services have that IP hardcoded.
Compliance and audit documentation — security posture records reference that IP in that VLAN.

VLANs add another dimension. In enterprise environments, VLANs aren’t just a way to segment traffic, they’re security boundaries, designed and owned by the security team. Firewall rules are built around VLAN membership. Compliance frameworks reference VLAN placement. When the VM moves to Kubernetes with default networking, that VLAN disappears. The security boundary is gone.

None of this travels with the VM automatically. And every broken dependency requires a different team to fix it.

You can see this directly. Running kubectl exec into the virt-launcher pod of a migrated VM shows the interfaces KubeVirt creates with default pod networking:

2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450
inet 10.60.141.196/32 scope global eth0
3: k6t-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450
inet 10.0.2.1/24 scope global k6t-eth0
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 master k6t-eth0

eth0 is a Calico-assigned pod CIDR address — meaningful only inside the cluster. k6t-eth0 is KubeVirt’s internal masquerade bridge. tap0 connects to the VM’s virtual NIC. The VM’s original IP is gone. The upstream network sees 10.60.141.196, not the address any firewall rule, DNS record, or application config was written for.

A lift-and-shift becomes a multi-team project

Here’s what was planned: the platform team moves the VM. One team. The migration is invisible to the rest of the business.

Here’s what actually happens with default pod networking:

The IP changes. The network team needs to rewrite firewall rules and update DNS
The VLAN disappears. The security team needs to review the new network placement and approve it
Application config breaks. The application team needs to update config files and hardcoded references

Every one of these requires sign-offs, tickets, and coordination

A migration budgeted as a lift-and-shift gets delivered as a network redesign. Per VM. At scale, the coordination cost makes migration impractical.

This is where VM migration to Kubernetes stalls, not because the technology doesn’t work, but because the organisational cost exceeds what anyone planned or funded for.

How to preserve VM IP addresses and VLANs in Kubernetes

Think about what the problem really is. The VM had a home on the network. A specific IP, a specific VLAN, a specific place in the security model. When it moved to Kubernetes, that home disappeared. Default pod networking gave it a new address in a new network that nothing outside the cluster knows about.

Calico L2 Bridge Networks solve this by doing the opposite. Calico L2 Bridge Networks extend a VM’s original Layer 2 network segment – including its IP address, VLAN, and MAC address – directly into a Kubernetes cluster via a node-level bridge, so the VM’s network identity survives the migration unchanged. Instead of putting the VM on Kubernetes’s network, it brings the VM’s original network into Kubernetes. The physical VLAN the VM lived on gets extended directly into the cluster via a bridge on the node. The VM connects to that bridge through a secondary interface, and the VM preserves its original IP address, the same VLAN, and the same MAC address it had before the migration.

Nothing on the outside knows anything has changed. The firewall still talks to the same IP. DNS still resolves to the right place. The monitoring dashboard still shows the right host. The application that had the IP hardcoded still connects. The security team’s VLAN boundary still exists — it just now exists inside Kubernetes too.

L2 Bridge Mode with Calico by Tigera

You can see the difference at the interface level. With Calico L2 Bridge, that same virt-launcher pod now looks like this:

2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450
   inet 10.60.141.196/32 scope global eth0
3: k6t-eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450
   inet 10.0.2.1/24 scope global k6t-eth0
4: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 master k6t-eth0
5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
   link/ether 52:54:00:3a:7f:21 brd ff:ff:ff:ff:ff:ff
   inet 10.10.5.42/24 brd 10.10.5.255 scope global net1

net1 is the secondary interface connected to the L2 bridge that Calico manages on the node. That’s the VM’s original IP10.10.5.42, on its original subnet, with its original MAC address. The pod-side interfaces are still there, KubeVirt still needs them, but the VM’s actual network identity is preserved on net1. That’s the interface the rest of your infrastructure talks to.

Why a secondary interface and not the primary?

KubeVirt manages the VM’s primary network interface through the virt-launcher pod. That primary interface has two modes: masquerade and bridge. Masquerade NATs all VM traffic through the pod’s IP. The VM is hidden behind the pod address. Bridge mode connects the VM to the pod network bridge. Closer, but still the pod network, not your VLAN.

Neither mode has a way to extend an external VLAN directly to the VM. They’re designed for pod networking, not for preserving legacy network identity.

The secondary interface is what makes this work. Calico attaches an additional interface to the VM and that interface connects to the bridge Calico created on the node, which connects to the trunk carrying your VLAN from the physical switch. The VM’s traffic on that interface goes directly to the right network segment without any translation or tunnelling.

How Calico sets it up

The setup is declarative. You define what you want, Calico handles the plumbing.

You create a network resource in Kubernetes that tells Calico which VLAN to bridge and how to map it. Calico reads that and creates the bridge on the node automatically, attaches the trunk interface, and starts tracking the VM’s IP. A NetworkAttachmentDefinition tells KubeVirt to attach the secondary interface at boot. The VirtualMachine spec references the secondary network, and when the VM starts, net1 appears with the right IP.

Migration tools like Forklift (for OpenShift Virtualisation) handle the mapping of existing VM interfaces to the cluster definitions and register the VM’s IP with Calico before migration. From that point, Calico owns the IP, tracking it, keeping routing state correct, and following the VM if it moves between nodes.

Multiple VLANs can run through the same trunk-backed bridge. You don’t need separate infrastructure per VLAN, the same bridge handles them all.

What you gain after the migration

Getting the VM into Kubernetes without breaking anything is the primary goal. But once it’s there, a few things become available that weren’t possible in the hypervisor environment.

Network visibility

In a traditional hypervisor setup, getting visibility into what a VM is actually doing on the network usually means deploying a separate agent, a network tap, or a dedicated monitoring tool per host. That visibility comes with the unified platform that Calico provides. Calico gives you traffic flow data, communication patterns, and network behaviour for VM interfaces without anything extra to install or manage.

Security policy you can actually version control

The firewall rules that protected this VM before migration were probably sitting in a security team’s ticketing system, applied manually to a physical or virtual firewall. They worked, but they weren’t portable, they weren’t reviewable in a pull request, and they weren’t easy to audit.

With Calico, you can express the same security posture as Kubernetes-native network policy. Labels, selectors, declarative YAML. You don’t have to do this immediately as part of the migration. The VLAN boundary still exists, the existing firewall rules still apply. But when the security team is ready to modernise the policy model, the tooling is already there.

Live migration that doesn’t touch the network

Once a VM is running in Kubernetes, it can move between nodes for patching, rebalancing, hardware failures, and the network configuration moves with it. Calico tracks the IP and updates routing state automatically. From the outside, nothing changes. The VM is just on a different node now.

Making VM migration to Kubernetes practical

Migration projects fail when the platform team scopes a job as “move the VM” and it turns into “rebuild the network.” That scope creep isn’t a technical failure, it’s what happens when you use a networking model designed for stateless containers to move workloads that were designed around stable, long-lived network identities.

Calico L2 Bridge Networks solve the right problem: keep the network identity intact during the move, let the migration stay within the platform team’s remit, and leave modernisation for when it’s actually planned and funded.

Move now. Modernise later. On your own timeline.

Watch our walkthrough to learn more: Calico L2 Bridge Networking for Virtual Machines

The post KubeVirt Networking: How to Preserve VM IP Addresses During Migration appeared first on Tigera – Creator of Calico.

Your AI Agents Are Autonomous. But Are They Accountable?

Alister Baroi — Fri, 17 Apr 2026 10:39:24 +0000

Why accountability, not capability, is the real bottleneck for enterprise agentic AI, and what security leaders need to do about it before regulators force the issue.

Every enterprise is building AI agents. Marketing has one summarizing campaign performance. Engineering has one triaging incidents. Customer support has one resolving tickets. Finance has one processing invoices. And increasingly, those agents are talking to each other: calling tools, accessing databases, delegating tasks across complex multi-hop chains.

But here’s the question nobody wants to hear at 3 a.m. when something goes wrong: who authorized that action, what policy permitted it, and what’s the full chain of events?

For most enterprises, the honest answer is: nobody knows. That’s not a governance problem — it’s an AI agent accountability crisis.

Agents Are Scaling Faster Than Governance

The data paints a stark picture. McKinsey research found that 80% of organizations have already encountered risky behavior from AI agents. These actions were unintended, unauthorized, or outside acceptable guardrails. Yet only about one-third of organizations report meaningful governance maturity. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls.

This isn’t a future problem. This is the mainstream enterprise experience with agentic AI right now. And the pattern should feel familiar. A decade ago, enterprises faced “shadow IT,” where employees adopting cloud services without IT approval created ungoverned sprawl that took years to bring under control. Today, agentic architectures risk creating a new back door for “shadow AI,” and the stakes are higher. Unlike cloud services, agents don’t just store data; they make decisions, call APIs, access databases, and propagate those actions across other agents in a chain that nobody can trace.

The Regulatory Clock

Compliance deadlines on both sides of the Atlantic are months away. The EU AI Act’s main provisions take effect in August 2026, requiring action logging, transparency, and human oversight for high-risk AI systems. In the US, the Colorado AI Act (being the leading regulation) takes effect in June 2026, mandating risk management programs and impact assessments for high-risk AI. And Colorado isn’t the only state: California, New York, Utah, and Texas have already enacted AI governance laws, and there are 80+ AI governance bills under consideration in the current US Federal Congress.

Two-thirds of industry leaders believe formal agent accountability frameworks will become mandatory within the next two years. The question isn’t whether these requirements are coming. It’s whether your organization will be ready.

Key Pillars for Agent Accountability

Not all “governance” is created equal. Many enterprises believe they have agent governance because they have network policies or an API gateway. But governance without accountability is security theater; it might prevent some bad outcomes, but it can’t prove why good outcomes were permitted, trace what happened when something goes wrong, or satisfy an auditor asking for evidence.

True agent accountability requires five distinct capabilities working together:

Traceability — Can you trace what happened, end to end? When Agent A calls Agent B, which calls Tool C, which accesses Database D, can you reconstruct the entire chain with timestamps and outcomes at every hop? Without traceability, incident response is guesswork.
Authorization provenance — Can you prove why it was permitted? Not just “Agent A was allowed to call Agent B,” but “Agent A was allowed to call Agent B because Policy X grants agents with capability Y access to agents with risk-level Z.” This is the difference between a lock on the door and a sign-in sheet.
Identity and ownership — Who owns this agent, and who is responsible when it acts? Every agent needs a verified identity and a clear human owner. Without it, accountability diffuses across components, and diffused accountability is no accountability at all.
Policy-based governance at scale — Does your security model survive agent #101? With 10 agents, you can manage permissions by hand. With 100, you can’t. Scalable governance requires declarative, attribute-based policies that grow with the network, not against it.
Human oversight and intervention — Can a human review, approve, or override? Effective oversight means visibility into what agents are doing, the ability to review interactions after the fact, and the power to modify policies or revoke access in real time.

If you’re missing any one of these pillars, you have a gap that will surface during your next incident, audit, or regulatory review.

Why Existing Approaches Can’t Deliver AI Agent Accountability

Enterprises aren’t starting from zero; most have invested in network policies, API gateways, RBAC, and protocols like MCP and A2A. The problem isn’t a lack of tools. It’s that these tools were designed for model outputs (a world where services are deterministic, communication patterns are predictable, and humans make all the decisions), not autonomous actions.

Network policies operate at the wrong abstraction level for agent accountability. They can say “pods in namespace A can reach pods in namespace B,” but they can’t say “Agent A with risk-level=low can only call agents with risk-level=low.” They have no concept of agent identity, capabilities, or policy attributes, and they produce no audit trail.

API gateways handle north-south traffic but don’t understand the east-west, multi-hop nature of agent-to-agent communication. MCP and A2A solve the how of agent communication, but explicitly assume someone else handles the who and the why. RBAC works at small scale but can’t express the nuanced, attribute-based policies that agent governance requires.

The industry has solved agent communication and agent infrastructure. What’s missing is the accountability layer — the control plane that answers three questions for every agent interaction: Who authorized this? What policy permitted it? What’s the full record?

The AI Governance Gap Is Growing

The enterprises that thrive in the agentic era won’t be the ones that deploy the most agents. They’ll be the ones that can prove their agents are operating within policy, trace every interaction end to end, and answer the question: who’s accountable when the agent acts?

We wrote a strategic guide to help you get there. Our whitepaper, Accountable AI Agents: A Strategic Guide for AI & Security Leaders Governing Autonomous AI at Scale, breaks down the full framework — the five pillars of agent accountability, why existing approaches leave gaps, and the architectural principles your governance platform needs to deliver. It also provides the solution, the accountability maturity model, which guides how to fix these security and accountability gaps. No product demos, no fluff. Just the blueprint your leadership team needs before the next incident or regulation forces your hand.

Get the strategic guide for accountable AI agents →

The post Your AI Agents Are Autonomous. But Are They Accountable? appeared first on Tigera – Creator of Calico.

Deployed Is Not the Same as Ready: How Mature Is Your Kubernetes Environment?

Alister Baroi — Thu, 16 Apr 2026 22:00:25 +0000

Kubernetes adoption is no longer the challenge it once was. More than 82% of enterprises run containers in production, most of them on multiple Kubernetes clusters. Adoption, however, does not mean operational maturity. These are two very different things. It is one thing to deploy workloads to a cluster or two and quite another to do it securely, efficiently and at scale.

This distinction matters because the gap between adoption and Kubernetes operational maturity is where risk accumulates. Operationally mature organizations ship faster, recover from incidents in minutes instead of hours and consistently pass compliance audits. They spend less time dealing with outages and more time delivering new services to their customers.

So what separates maturity from adoption? It comes down to a handful of foundational capabilities that, when done well, result in measurable business impact. Operational maturity — the ability to run Kubernetes workloads securely, efficiently, and at scale, with consistent policy enforcement, cross-cluster observability, and automated incident recovery — is not a destination; it is a continuous process of strengthening the architectural pillars that keep your Kubernetes environment production-ready.

What does operational maturity look like?

Operational maturity spans several interconnected areas from Kubernetes security best practices to observability and multi-cluster connectivity that, taken together, determine how resilient, secure, and observable your Kubernetes environment truly is. One practical way to measure this is to walk through the capabilities your environment either has or does not have yet.

A running vs an operationally mature Kubernetes environment

Can you effectively isolate workloads from each other?

The flat network default which allows pods to be created, destroyed and moved on the fly (a core Kubernetes capability) also creates a wide-open door for lateral movement if a workload is compromised.

A tiered policy model addresses this by organizing network policies into layers of precedence, each owned by a different team. Security teams define high-priority guardrails—for example, blocking traffic to malicious destinations, enforcing tenant isolation—while platform teams secure infrastructure components and developers write fine-grained rules for their own applications. This separation of duties eliminates policy sprawl and ensures that a developer-created rule can never accidentally override a critical security baseline.

Do you have a zero-trust security policy with pod to pod encryption and workload identity?

In addition to isolation, security means a zero trust posture, and that in turn means mTLS for internal cluster traffic. mTLS has become a hard requirement, both for regulators and for security teams that have learned the hard way what unencrypted east-west traffic costs when something goes wrong.

For organizations that have given up on service mesh, Istio ambient mode is worth a look. It delivers automatic mTLS and SPIFFE-based workload identity across all traffic without the resource cost of sidecars. L7 capabilities such as traffic shaping and advanced observability can be layered in selectively only for the services that need them.

Security is the foundation and non-negotiable starting point on the journey towards a mature Kubernetes posture.

Does your ingress solution have all the capabilities you need without relying on vendor-specific annotations?

The retirement of Ingress NGINX Controller was a wake up call for many organizations making them realize that ‘good enough’ is, in fact, not good enough. Migrating to a robust and future proof implementation of Gateway API is one more step along the road to operational maturity.

Ingress and traffic management are evolving rapidly. The Kubernetes Ingress API served its purpose for years, but reliance on annotations, limited protocol support, and a single-controller model have become constraints at scale. The Gateway API replaces it with a role-oriented model. This is more than a technical upgrade. It is a shift not only towards more granular and comprehensive traffic control but towards decentralized management where cluster administrators control the infrastructure and development teams define their application-specific routing rules.

Is egress getting the attention it needs?

Egress traffic management is the often overlooked sibling of ingress control. Without dedicated egress controls, outbound traffic from your cluster uses the node’s IP address, which means different tenants and workloads become indistinguishable to the outside world. This makes audit trails unreliable, complicates compliance, and creates real security exposure.

An egress gateway architecture assigns each tenant or namespace a dedicated, static IP address for outbound traffic. External services can then allowlist those specific addresses, firewall rules become deterministic, and your security team can trace any outbound connection back to the workload that initiated it.

If your pods need to access external endpoints egress control deserves a place on your maturity roadmap, not on the back burner.

How do you connect your clusters?

It is rare to find organizations with just one Kubernetes cluster in production. Spectro Cloud reported that large enterprises operate more than 20 clusters across five or more cloud environments. If you are running AI workloads that are more than a simple API for the company chatbot, deploying a multi-cluster architecture that isolates GPU heavy training jobs from inference endpoints is a baseline expectation.

Unfortunately, the traditional multi-cluster architecture, which relies on external DNS and load balancers, exposes your internal services and presents a real risk. Beyond the security exposure, it introduces operational drag that compounds with every cluster you add. We are talking about frustrating DNS propagation delays, security policies that have to be manually synchronized across environments and, of course, the inevitable configuration drift.

Cluster mesh architecture, with its unified observability, Kubernetes-native service discovery that does not rely on external DNS and consistent inter-cluster security policies, is what can keep a complex multi-cluster environment from becoming a liability. Multi-cluster done well is a reliable measure of operational maturity.

Are you relying solely on hardware load balancers

Hardware load balancers were built for a pre-Kubernetes world. They have no native concept of pods, services, or namespaces, and every configuration change typically requires a ticket, a separate team, and a procurement cycle. As Kubernetes becomes the default platform for production workloads, that operational friction compounds. The more clusters you run and the more latency-sensitive your workloads become, the more the limitations of hardware-centric load balancing show up in your incident logs and your budget.

A Kubernetes-native load balancer replaces the appliance with software that runs inside the cluster and understands its abstractions. Capacity scales horizontally by adding nodes, not by upgrading hardware. Configuration uses standard Kubernetes resources, which means no separate management console and no version drift between your cluster and your load balancer. For teams managing payment processing, trading systems, or real-time data pipelines, the combination of eBPF-based forwarding, consistent hashing, and graceful node draining delivers the reliability of enterprise appliances without the operational overhead.

Is your team still stitching together clues from kubectl and scattered logs, or do you have a single, unified view across your entire environment?

Kubernetes environments can fail quietly. Services degrade, traffic patterns shift, and workloads compete for resources in ways that are invisible without the right instrumentation in place. In a single cluster, experienced engineers can often piece together what is happening from logs and metrics. Across multiple clusters, namespaces, and workload types that approach becomes highly inefficient and costly. Managing cost and efficiently tracking down problems is even harder, and more imperative, now that AI workloads, with their training jobs, inference endpoints and non-deterministic agents, often share infrastructure and resources with business-critical services.

Unified observability is essential to keeping all the moving parts manageable. Without Kubernetes-aware telemetry that is enriched with metadata about namespaces, services, and workload identity teams are operating blind. Mature observability means you can detect anomalous traffic patterns in real time, trace requests across cluster boundaries, and generate the audit evidence that compliance frameworks demand. It turns reactive firefighting into proactive operations. Organizations that strive for operational maturity cannot do without it.

Where are you on the journey to operational maturity?

Where do you stand?

No organization achieves Kubernetes operational maturity overnight, and not everything needs to be optimized immediately. What matters is knowing where you stand today so you can prioritize items that will have the greatest impact on your security posture, operational efficiency, and ability to support your current and future workloads. Whether you are still relying on default-allow networking, beginning to explore egress controls, or already running a multi-cluster mesh, there is always a next step on the maturity curve.

Read our ebook, Building Resilient Multi-Cluster Kubernetes to get a practical framework for closing the gap between Kubernetes adoption and operational readiness.

The post Deployed Is Not the Same as Ready: How Mature Is Your Kubernetes Environment? appeared first on Tigera – Creator of Calico.

Beyond the Prompt: AI Agent Design Patterns and the New Governance Gap

Alister Baroi — Wed, 15 Apr 2026 19:25:41 +0000

If you are treating Large Language Models (LLMs) like simple question-and-answer machines, you are leaving their most transformative potential on the table. The industry has officially shifted from zero-shot prompting to structured AI agent design patterns and agentic workflows where AI iteratively reasons, uses external tools, and collaborates to solve complex engineering problems. These design patterns are the architectural blueprints that determine how autonomous Agentic AI systems work and interact with your infrastructure.

But as these systems proliferate faster than organizations can govern them, they introduce a critical AI agent security risk: By the end of 2026, 40% of enterprise applications will feature embedded AI agents, and those teams will urgently need purpose-built strategies to govern this new autonomous workforce before it becomes the next major shadow IT crisis.

Before you can secure these autonomous systems, you have to understand how they are built. Here is a technical breakdown of the current AI Agent design patterns you need to know, and the specific security blind spots each design pattern creates.

1. The Foundational Execution Patterns

Building reliable AI systems comes down to how you route the cognitive load. Here are the three baseline structural patterns:

A. The Single Agent (Tool Use)

In this pattern, a single LLM is equipped with access to external, deterministic tools (APIs, databases, bash environments, or the Model Context Protocol).

How it works: The agent receives a prompt, realizes it lacks the necessary context, calls a tool, ingests the output, and formulates a final response.
The Governance Challenge: When an agent is granted API keys to query your cluster, it operates with implicit trust to access that data. If compromised via prompt injection, that single agent becomes an unmonitored vector for data exfiltration.

B. The Sequential Agent (The Assembly Line)

When a single agent fails at a complex task, we break the task down into a pipeline. Sequential agents operate in a linear hand-off, where the output of Agent A becomes the input of Agent B.

How it works: You deploy specialized micro-agents. Agent 1 extracts data, Agent 2 analyzes it, and Agent 3 formats the final report.
The Governance Challenge: As data flows between agents, maintaining an audit lineage becomes incredibly complex. You cannot easily trace which tools Agent 2 called based on Agent 1’s corrupted input.

C. The Parallel Agent (Concurrency & Voting)

To combat the latency of sequential pipelines, the Parallel pattern fans out tasks to multiple specialized agents simultaneously.

How it works: A router agent delegates sub-tasks to multiple worker agents concurrently. Once they finish, a “Judge” or “Synthesizer” agent aggregates the parallel outputs into a cohesive result.
The Governance Challenge: You now have multiple autonomous agents acting concurrently. Traditional security tools built for deterministic services cannot provide the visibility or control required for these non-deterministic autonomous actions.

2. The Advanced Cognitive Patterns That Complicate AI Agent Security

To make agents truly autonomous, developers are giving them the ability to “think” about their own work. These cognitive patterns drastically improve output quality, but introduce severe behavioral unpredictability.

A. The Reflection Pattern (Critic & Refiner)

The Reflection pattern pairs a Generator agent with a Critic agent.

How it works: The Generator outputs a first draft. The Critic evaluates it against guardrails, and the Generator iteratively refines the output until it passes the Critic’s checks.
Why it matters: Wrapping an older model (like GPT-3.5) in a Reflection loop often produces higher-quality, more reliable code than a zero-shot prompt to a cutting-edge model (like GPT-5.4 Pro).

B. The Planning Pattern

For highly ambiguous goals, agents need the autonomy to devise their own roadmaps.

How it works: Given a high-level goal, the Planning agent decomposes it into a Directed Acyclic Graph (DAG) of sub-tasks. It executes the plan step-by-step, adapting dynamically if a step fails (e.g., “Dependency missing, re-routing to fetch from alternate repo”).
The Governance Challenge: AI agents don’t follow scripts. They autonomously choose which tools to call, which data to access, and which agents to collaborate with, making static security models completely obsolete.

3. The Cold Start Problem: Why AI Agent Governance Can’t Wait

The ultimate evolution of these patterns is Multi-Agent Collaboration , a “society of minds” system where diverse agents with distinct personas (The Architect, The Security Engineer, The QA Tester) debate, share data, and execute code collaboratively across boundaries. AI agent security — the discipline of discovering, controlling, and auditing what autonomous agents can access and do — requires a fundamentally different approach than traditional application security. Each pattern described above introduces distinct risks, and in combination, they create attack surfaces that traditional security models were never designed to handle.

But as AI/ML engineering teams race to deploy and scale these Agent-to-Agent (A2A) architectures, most enterprises realize they don’t have any inventory of the AI agents running in their environment, including shadow agents deployed by teams outside official channels. A massive infrastructure challenge arises: How do these agents communicate securely? You cannot govern what you cannot see.

Whether your AI agents run in Kubernetes, cloud environments, on-premises, at the edge, or on developer laptops, governance that only covers one environment is governance with holes.

Enter Tigera Agent Governance (TAG)

We are moving past the era of human-in-the-loop chat interfaces into human-on-the-loop autonomous systems. To bridge this gap, Tigera is introducing TAG: the platform with the discipline to discover, authenticate, authorize, enforce, and audit every agent action, wherever agents run.

TAG is the first platform to own the full five-pillar framework required for modern AI workloads:

Discovery: Central registry and auto-discovery of shadow agents across your infrastructure.
Authentication: Cryptographic trust giving every agent a verified identity.
Authorization: Default-deny, fine-grained access control with tool-level binding.
Enforcement: Real-time enforcement that enables development velocity without bureaucratic blockers.
Governance: Full audit lineage, service graph visualization, and board-ready compliance reporting.

Your AI agents are making decisions. Do you know what they’re authorized to do? Do not wait for an autonomous agent to go rogue. Secure your next-generation architecture with universal governance built for the Agentic AI era.

→ Request Early Access to TAG

The post Beyond the Prompt: AI Agent Design Patterns and the New Governance Gap appeared first on Tigera – Creator of Calico.

How to Stub LLMs for AI Agent Security Testing and Governance

Alister Baroi — Thu, 02 Apr 2026 14:15:28 +0000

_ Note: The core architecture for this pattern was introduced by Isaac Hawley from Tigera._

If you are building an AI agent that relies on tool calling, complex routing, or the Model Context Protocol (MCP), you’re not just building a chatbot anymore. You are building an autonomous system with access to your internal APIs.

With that power comes a massive security and governance headache, and AI agent security testing is where most teams hit a wall. How do you definitively prove that your agent’s identity and access management (IAM) actually works?

The scale of the problem is hard to overstate. Microsoft’s telemetry shows that 80% of Fortune 500 companies now run active AI agents, yet only 47% have implemented specific AI security controls. Most teams are deploying agents faster than they can test them.

If an agent is hijacked via prompt injection, or simply hallucinates a destructive action, does your governance layer stop it? Testing this usually forces engineers into a frustrating trade-off:

Use the real API (Gemini, OpenAI): Real models are heavily RLHF’d to be safe and polite. It is incredibly difficult (and non-deterministic) to intentionally force a real model to “go rogue” and consistently output malicious tool calls so you can test your security boundaries.
Mock the internal tools only: You test your Python or Go functions in isolation, but you never actually test the “Agent Loop”—meaning you aren’t testing if the harness correctly applies the user’s OAuth tokens or Role-Based Access Control (RBAC) to the LLM’s requested tool call.

Recently, Isaac Hawley introduced a much better pattern: The Stub Model —a way to stub your LLM for testing that makes your security assertions completely deterministic.

A Stub Model (or mock LLM) is a deterministic, non-AI replacement for a real language model that you inject into your agent harness during testing. It returns hardcoded tool-call requests — including deliberately malicious ones — so you can prove that your security layer correctly intercepts and blocks unauthorized actions without relying on a live model API.

The Core Concept: A “Malicious” Router for AI Agent Security Testing

Instead of hitting a real model API during tests, we inject a StubLLM that implements our system’s core LLM interface.

The stub doesn’t use any AI. Instead, it parses incoming prompts for specific testing triggers and returns hardcoded, completely predictable tool calls. Crucially, this forces your agent harness to actually execute the real underlying tool pipeline. You aren’t just faking a final text response; you are making the LLM trigger your application’s real execution loop.

From a governance perspective, this is a superpower. You can program the stub to request highly privileged actions (like drop_database orread_all_users), and then write strict, lightning-fast assertions to prove that your Agent Harness intercepts the call, checks the executing user’s identity, and blocks the action.

Here is how you can implement and test this security pattern in both Python and Go.

Python: Proving RBAC & Tool Governance

In Python, we use a Protocol to define our LLM dependency, and then build a Stub that intentionally requests unauthorized actions.

from typing import List, Optional, Protocol
from pydantic import BaseModel
# Define standard tool call response formats
class ToolCall(BaseModel):
   id: str
   name: str
   arguments: dict
class Response(BaseModel):
   content: Optional[str] = None
   tool_calls: Optional[List[ToolCall]] = None
# Define the LLM Interface
class LLMClient(Protocol):
   def generate(self, prompt: str) -> Response:
       ...
# Implement the Stub Model for Security Testing
class StubLLM:
   def generate(self, prompt: str) -> Response:
       # 1. Standard authorized action
       if "MOCK_WEATHER_TOOL" in prompt:
           return Response(
               tool_calls=[ToolCall(id="call_1", name="get_weather", arguments={"location": "London"})]
           )

       # 2. Malicious / Unauthorized action for Governance testing
       if "MOCK_UNAUTHORIZED_DELETE" in prompt:
            return Response(
               tool_calls=[
                   ToolCall(
                       id="call_malicious_999",
                       name="delete_user_account",
                       arguments={"user_id": "admin_01"} # The LLM is trying something dangerous!
                   )
               ]
           )
       return Response(content="This is a stubbed standard response.")

The Security Unit Test (pytest): With the stub in place, we can test that our Agent correctly parses the dangerous tool call, evaluates the user’s identity, and blocks the execution of the real local Python function.

import pytest
def test_agent_rbac_blocks_unauthorized_tool_execution():
# Arrange: Inject our deterministic stub into the Agent
stubbed_llm = StubLLM()
# Initialize our agent harness with a heavily restricted "guest" identity
agent = Agent(llm_client=stubbed_llm, user_role="guest_user")
# Act: Send the trigger that forces our stub to attempt a destructive tool call
response = agent.run("Please MOCK_UNAUTHORIZED_DELETE")
# Assert: Verify the Agent's governance harness intercepted the call,
# checked the "guest_user" identity, and blocked the REAL local tool.
assert response.status == "blocked_by_policy"
assert response.tool_executed is None
assert "Insufficient permissions to execute delete_user_account" in response.error_message

Go: Validating OAuth & Identity Boundaries

In Go, this pattern shines for validating complex OAuth scopes or identity propagation in multi-agent networks.

package llm
import (
   "encoding/json"
   "strings"
)
type ToolCall struct {
   ID string `json:"id"`
   Name string `json:"name"`
   Arguments []byte `json:"arguments"`
}
type Response struct {
   Content string `json:"content,omitempty"`
   ToolCalls []ToolCall `json:"tool_calls,omitempty"`
}
type Client interface {
   Generate(prompt string) (*Response, error)
}
type StubLLM struct{}
func NewStubLLM() *StubLLM {
   return &StubLLM{}
}
func (s *StubLLM) Generate(prompt string) (*Response, error) {
   // Simulate an Agent trying to access a secure internal system via MCP
   if strings.Contains(prompt, "MOCK_ACCESS_SECURE_VAULT") {
       args, _ := json.Marshal(map[string]string{"secret_id": "prod_db_password"})

       return &Response{
           ToolCalls: []ToolCall{
               {
                   ID: "call_vault_123",
                   Name: "read_secure_vault",
                   Arguments: args,
               },
           },
       }, nil
   }
   return &Response{Content: "Standard response"}, nil
}

The Security Unit Test (testing): We write a test to guarantee that if the LLM decides to hit the vault, the Agent harness forces the underlying tool to respect the provided OAuth context.

package agent_test
import (
"testing"
"errors"
)
func TestAgentEnforcesOAuthScopes(t *testing.T) {
// Arrange: Initialize the agent with the Stub model
stub := llm.NewStubLLM()
// Create an agent context with a standard user OAuth token (No Vault Access)
mockOAuthContext := identity.NewContext(identity.WithScope("read:public"))
myAgent := agent.New(stub, mockOAuthContext)
// Act: Trigger the LLM to request a highly privileged tool call
result, err := myAgent.Run("I need you to MOCK_ACCESS_SECURE_VAULT")
// Assert: Verify the harness evaluated the tool against the OAuth scope and blocked it
if err == nil {
t.Fatalf("CRITICAL SECURITY FAILURE: Agent executed secure vault tool without proper OAuth scope")
}
if !errors.Is(err, ErrUnauthorizedToolExecution) {
t.Errorf("Expected authorization error, got: %v", err)
}
if result.ExecutedTool == "read_secure_vault" {
t.Errorf("The real tool was executed despite lack of permissions!")
}
}

Why Security & Governance Teams Love This Architecture

By treating the LLM like any other untrusted external dependency, we achieve total control over our agent’s testing environment.

Auditable Proof of Governance: You now have concrete CI/CD tests proving that your agent respects OAuth scopes, RBAC, and identity guardrails. You aren’t just hoping the model behaves; you are proving the harness defends against it when it doesn’t.
Tests the Real Agent Harness: Because the LLM returns a perfectly formatted tool call request, your application code actually executes its real security middleware. You validate the entire execution loop, not just a mocked final answer.
Lightning Fast & Free: You can run thousands of these security edge-case tests in milliseconds without spending a dime on API tokens or exposing secrets in your CI pipeline.
Force Prompt Injection Scenarios: You can easily stub the LLM to return tool arguments containing SQL injection or XSS payloads to ensure your local tools sanitize inputs provided by the AI.

The Trade-Offs: What the Stub Model DOESN’T Test

As powerful as this architecture is for testing your infrastructure, it’s important to acknowledge that it is not a silver bullet. There are two major things the Stub Model cannot test:

It tests the pipes, not the brain: The stub proves your system can correctly block a malicious tool call, but it does not test whether your system prompt is resilient to prompt injection in the first place. You still need LLM-as-a-judge pipelines and continuous evaluation frameworks to test your model’s actual reasoning capabilities.
Vendor Schema Drift: If OpenAI, Anthropic, or Google update the shape of their underlying JSON tool-call schema, your hardcoded stub tests will still pass with flying colors while your production environment crashes. You still need a handful of real, end-to-end (E2E) smoke tests running against the live API on a nightly basis to catch vendor drift.

Beyond the Chatbot: Engineering for Agency

If you are building complex systems, delegating between autonomous agents, or integrating internal APIs via MCP, you cannot afford to have untested authorization loops.

By treating the LLM like any other untrusted external dependency, we achieve total control over our agent’s testing environment. We gain auditable proof of governance , ensuring we can run thousands of CI/CD tests in milliseconds without exposing secrets or spending a dime on API tokens.

If you are building complex systems, delegating between autonomous agents, or integrating internal APIs via MCP, you cannot afford to have untested authorization loops.

Do yourself a favor: Stub your LLMs.

Stubbing your LLM proves the guardrails work in test. TAG enforces them in production, giving you continuous visibility into every agent action, authorization decision, and policy enforcement event across your entire organization. Talk to us about TAG.

The post How to Stub LLMs for AI Agent Security Testing and Governance appeared first on Tigera - Creator of Calico.

Introducing AI Assistant for Calico, Calico Load Balancer, and Seamless VM-to-Kubernetes Migration

Alister Baroi — Mon, 23 Mar 2026 07:01:36 +0000

SAN JOSE, Calif., March 23, 2026 — Tigera, the creator and maintainer of Project Calico, today announced a major expansion of its Unified Network Security Platform for Kubernetes, aimed at helping enterprises consolidate infrastructure and accelerate the migration of legacy workloads to cloud-native platforms.

The new capabilities include:

Al Assistant for Calico: A proactive, conversational intelligence layer that replaces complex manual log analysis with natural-language troubleshooting and proactive security audits.
Calico Load Balancer: A high-performance, eBPF-based, software-defined load balancer that replaces expensive, rigid hardware appliances with a Kubernetes-native solution.
Seamless VM-to-Kubernetes Migration: Advanced Layer 2 (L2) networking support eliminates migration friction by allowing virtual machines to move into Kubernetes clusters without changing their original IP addresses or existing VLAN dependencies.

These innovations help organizations tackle the rising “complexity tax” in managing high-scale Kubernetes clusters and provide a high-velocity path to consolidate virtual machines and containers into a single, standardized platform.

“The industry is at a breaking point where the operational overhead of managing legacy hardware and fragmented VM silos is no longer sustainable. By building a distributed load balancer into the fabric of Calico, launching an Al assistant that ‘troubleshoots at the speed of thought,’ and introducing live migration support to move VMs to Kubernetes, we are giving platform teams the power to innovate rather than spend hours managing and troubleshooting.”

— Ratan Tipirneni, president and CEO, Tigera

Troubleshooting at the Speed of Thought: Introducing an Al Assistant for Calico

Despite the wealth of telemetry available in modern clusters, SREs often struggle to find the “connecting thread” across isolated events. Calico’s Al Assistant provides a context-aware intelligence layer to extract actionable insights from raw telemetry.

Ask, Don’t Query: Engineers can move away from rigid query languages and toward articulating intent in plain English. For example: “What are the unrestricted egress destinations currently receiving traffic from my pods?”
Context-Aware Explanations: The assistant provides summaries and recommendations generated from real telemetry and policy context, explaining exactly why traffic is being denied and offering remediation advice.
Proactive Security: Beyond troubleshooting, the Al assistant maintains cluster stability by detecting unused network policies, identifying misconfigurations, and surfacing exposure risks before they cause an outage.

Explore the full capabilities: How the AI Assistant for Calico simplifies troubleshooting at the speed of thought.

Eliminating Hardware Bottlenecks: The Calico Load Balancer

On-premises Kubernetes teams have traditionally relied on legacy hardware appliances to expose services, creating significant operational overhead and rigid dependencies between networking and platform teams. These external solutions often lack visibility into Kubernetes service context, do not scale horizontally, and require manual coordination for even basic software upgrades.

Tigera is disrupting this model with the Calico Load Balancer, a modern, software-defined solution built natively into the Calico platform. By transforming existing cluster nodes into a distributed, session-stable load-balancing tier, platform teams gain full control over service advertisement and configuration using the same Kubernetes workflows they already use.

This Kubernetes-native innovation delivers several critical advantages:

Session Persistence for Stateful Apps: A high-performance, eBPF-based data plane ensures that latency-sensitive, stateful applications like Kafka or RabbitMQ maintain active connections even during node failures or changes in network paths.
Graceful Node Restarts: Platform teams can mark nodes for maintenance and take them offline without impacting user sessions, preventing lost transactions for critical business services.
Reduced Latency: By enabling return traffic to take a shorter path back to the client, the solution reduces latency compared to traditional appliances where traffic must pass through the same central hardware twice.
Simplified Scaling: The load balancer scales horizontally with the cluster; adding more nodes automatically adds more load-balancing capacity without vertical scaling limits or vendor upgrade cycles.
Self-Service and Declarative Control: Configuration is handled through standard Kubernetes resources and GitOps workflows, removing cross-team bottlenecks and eliminating the need for tickets or separate management consoles.

Technical Deep Dive: Simplifying network traffic management with eBPF and the Calico Load Balancer.

The Great Migration: Seamlessly Moving VMs to Kubernetes

Historically, migrating virtual machines to Kubernetes meant a forced network redesign because VMs rely on static IP addresses and legacy Layer 2 VLAN configurations. Tigera’s new L2 networking support removes this friction.

Zero-Change Migration: VMs can be migrated from VMware to Kubernetes (KubeVirt) while keeping their original IP addresses, ensuring business continuity for applications with hardcoded dependencies.
Instant Security Upgrade: Once migrated, VMs are automatically protected by Calico’s microsegmentation, allowing organizations to retire costly third-party security tools.

Once migrated, the VMs in Kubernetes benefit from Calico’s advanced network security and observability capabilities. For users familiar with technologies like VMware NSX, Calico provides NSX-like functionality, including software-defined networking, microsegmentation, a workload-based firewall, and egress gateways for VMs running in Kubernetes.

Step-by-Step Guide: Lift and shift VMs to Kubernetes with Calico L2 bridge networks.

One Platform for Networking, Security, and Observability

The new Calico Unified Network Security Platform provides platform teams with a single, operator-managed solution. This allows teams to gain consistent network policy enforcement across L3-L7 layers with unified visibility, eliminating the overhead of managing multiple tools. Calico works consistently across any Kubernetes distribution, virtual machines, and bare-metal servers, ensuring enterprises can avoid vendor lock-in.

About Tigera

Tigera provides Calico, a unified network security and observability platform to prevent, detect, and mitigate security breaches in Kubernetes clusters. Tigera’s open-source offering, Calico Open Source, is the most widely adopted container networking and security solution. Powering more than 100M containers across 8M+ nodes, Calico is supported across all major cloud providers and Kubernetes distributions.

Media Contact

Media relations, Tigera

contact@tigera.io

Next Steps: Get Hands-on with These Innovations

Learn more about AI Assistant, Calico Load Balancer, and L2 networking support within the Calico ecosystem. Whether you are looking to optimize troubleshooting, reduce hardware dependency, or accelerate your VM migration, we provide the tools to get started today.

Experience the Platform: Start a free trial of Calico Cloud
Personalized Deep Dive: Request a technical demo with our engineering team

Attending KubeCon Amsterdam? Stop by the Tigera booth #400 to learn more about these features.

The post Introducing AI Assistant for Calico, Calico Load Balancer, and Seamless VM-to-Kubernetes Migration appeared first on Tigera - Creator of Calico.

Secure and Scale VMware VKS with Calico Kubernetes Networking

Alister Baroi — Sun, 22 Mar 2026 18:50:39 +0000

Co-authors

Abhishek Rao | Tigera

Ka Kit Wong, Charles Lee, & Christian Rauber | Broadcom

VMware vSphere Kubernetes Service (VKS) is the CNCF-certified Kubernetes runtime built directly into VMware Cloud Foundation (VCF), which delivers a single platform for both virtual machines and containers. VKS enables platform engineers to deploy, manage, and scale Kubernetes clusters while leveraging a comprehensive set of cloud services. And with VKS v3.6, that foundation just got significantly more powerful: VKS now natively supports Calico Enterprise — part of the Calico Unified Platform — as a validated, lifecycle-managed networking add-on through the new VKS Addon Framework.

Even better, VKS natively integrates Calico Open Source by Tigera as a supported, out-of-the-box Container Network Interface (CNI). This gives organizations a powerful open source baseline right from day one:

Pluggable Data Planes: The flexibility to run high-performance eBPF, standard Linux iptables, modern nftables, or Windows data planes based on specific workload needs.
Wire-Speed Routing: Direct BGP peering with the underlying VMware NSX infrastructure, eliminating the performance overhead of traditional overlay networks.
Foundational Zero-Trust: Global default-deny policies to instantly secure pod-to-pod traffic.
Observability: Includes Whisker, a visual UI tool that simplifies access to flow logs, making it easier to analyze network communication and debug policies.

VKS and Calico Open Source build the perfect house for your applications. However, as Kubernetes adoption explodes across the enterprise, platform engineering and security teams inevitably hit a new wall.

What happens when your security team mandates strict compliance audits across 50 different clusters? What happens when you need to route ephemeral Kubernetes traffic through your legacy physical firewalls? Or when a critical microservice drops traffic at 2 AM and you need to know exactly why?

To conquer the complex realities of production scale, organizations running VKS are supercharging their environments with the Calico Unified Platform (available via Calico Enterprise and Calico Cloud). Here is how Calico transforms your baseline VKS clusters into a fully observable, enterprise-grade networking and security platform.

The Calico Unified Platform Reference Architecture

As you scale your VKS environment, your architecture must evolve from providing basic pod connectivity to delivering a comprehensive security, routing, and observability mesh.

The reference architecture below illustrates how Calico Unified Platform wraps your VKS worker nodes in advanced Layer 7 protections, granular egress controls, and deep forensic logging capabilities—all while maintaining the high-performance eBPF and BGP foundation of your clusters.

Calico Unified Platform Architecture

Figure 1: Calico Unified Platform reference architecture for VKS – showing how Calico Enterprise wraps VKS worker nodes with Layer 7 security, egress controls, and deep observability while preserving the eBPF and BGP performance foundation.

1. Secure the Perimeter: Bridging Kubernetes with Legacy Firewalls

Traditional network security teams often struggle with Kubernetes because Pod IP addresses are ephemeral—they spin up and die in seconds. This makes it virtually impossible to write static firewall rules on your external Palo Alto or Fortinet appliances.

The Calico Unified Platform bridges this gap seamlessly for VKS environments:

Egress Gateway & Source NAT: Calico allows you to map dynamic Kubernetes namespaces to highly available, static IP Egress Gateways. When a pod talks to the outside world, your external firewall only sees the static IP. No more fighting with the NetSec team over IP tracking!
Native WAF and IDS/IPS: Secure your inbound traffic right at the Calico Ingress Gateway. Calico integrates a powerful Web Application Firewall (WAF) using the ModSecurity Core Rule Set. Coupled with native Intrusion Detection/Prevention (IDS/IPS) and DDoS protection, Calico detects and blocks malicious payloads before they impact performance.
DNS Policies & Threat Feeds: Do not just block IPs; block malicious domains. Calico dynamically ingests global threat intelligence feeds to automatically halt traffic to known bad actors.

2. Enforce Zero-Trust at Scale: Unified Policy Across Kubernetes, VMs, and Bare Metal

Open-source network policies are fantastic, but managing them across dozens of teams and clusters can quickly turn into the “Wild West” of YAML files. Calico brings true enterprise governance to your VKS environment—and extends it well beyond Kubernetes:

Network Policy Tiers & Staged Policies: A hierarchical, RBAC-driven approach to security. The Security team can create non-overrideable “Tier 1” guardrails, while Developers get full freedom to write microsegmentation rules for their specific namespaces. Even better, with Staged Policies, you can preview and test the impact of any rule on live traffic before fully enforcing it, ensuring zero downtime.
Unified Protection for Legacy VMs & Bare Metal: Your VKS clusters do not exist in a vacuum. Calico extends its policy engine beyond Kubernetes, allowing you to secure traditional VMware VMs and bare-metal servers using the exact same single-pane-of-glass dashboard—a headline differentiator of the Calico Unified Platform.
Sidecar-Less Service Mesh (Istio Ambient Mode): Get the deep L7 visibility and mTLS encryption of a service mesh without the crippling performance overhead. Calico seamlessly integrates with Istio Ambient Mesh, managed through a single Calico operator—no standalone Istio expertise required.

3. Total Visibility: One Management Plane for Every Traffic Flow

When a connection fails in a standard K8s cluster, troubleshooting usually involves blindly digging through kubectl logs. It is slow, frustrating, and drastically inflates your Mean Time to Resolution (MTTR).

Calico acts as the ultimate CCTV system for your VKS clusters—with a single console covering every traffic type, from ingress to egress to pod-to-pod:

Dynamic Service Graph & Alerts: Get a real-time visual map of all microservice traffic across your clusters. Instantly see performance metrics, blocked traffic, and active connections. You can even configure automated alerts and incident response to deploy mitigating policies the second an anomaly is detected.
Deep Forensic Logging: Calico goes far beyond basic flow logs. It provides granular DNS Logs, L7 Logs, and Ingress Logs, allowing you to pinpoint exactly which layer of the stack is failing.
On-Demand Packet Capture: Did a specific pod trigger an anomaly? Trigger a targeted packet capture (pcap) directly from the Calico UI for deep forensic analysis, without ever having to SSH into the vSphere worker nodes.

4. Scale Without Limits: Multi-Cluster Management and AI-Powered Operations

As your VMware footprint grows, managing clusters individually becomes impossible. Calico’s Multi-Cluster Management provides a single pane of glass to view, secure, and troubleshoot all your VKS clusters—and even your public cloud EKS/AKS clusters. You can seamlessly federate identities and extend resilient multi-cluster networking with Cluster Mesh.

And when things get truly complex? AI Assistant for Calico serves as your platform co-pilot. You can use natural language prompts to generate declarative Policy as Code, query flow logs, and diagnose active threats, drastically reducing the learning curve for new team members.

The Ultimate VKS Experience

VMware VKS gives you a world-class, CNCF-certified Kubernetes platform built directly into VCF. Calico Enterprise — part of the Calico Unified Platform — takes that foundation further, delivering a single management plane for networking, network security, and observability across every cluster, every workload type, and every environment. No stitching tools together. No integration tax. Just the enterprise-grade performance and security your most critical workloads demand.

Ready to see it in action?

Request a Demo of Calico Enterprise →

Start your free trial of Calico Cloud today →

The post Secure and Scale VMware VKS with Calico Kubernetes Networking appeared first on Tigera - Creator of Calico.

Calico Load Balancer: Simplifying Network Traffic Management with eBPF

Alister Baroi — Sat, 21 Mar 2026 20:00:55 +0000

Authors: Alex O’Regan, Aadhil Abdul Majeed

Ever had a load balancer become the bottleneck in an on-prem Kubernetes cluster? You are not alone. Traditional hardware load balancers add cost, create coordination overhead, and can make scaling painful. A Kubernetes-native approach can overcome many of those challenges by pushing load balancing into the cluster data plane. Calico Load Balancer is an eBPF powered Kubernetes-native load balancer that uses consistent hashing (Maglev) and Direct Server Return (DSR) to keep sessions stable while allowing you to scale on-demand.

Below is a developer-focused walkthrough: what problem Calico Load Balancer solves, how Maglev consistent hashing works, the life of a packet with DSR, and a clear configuration workflow you can follow to roll it out.

Why a Kubernetes-native load balancer matters

On-prem clusters often rely on dedicated hardware or proprietary appliances to expose services. That comes with a few persistent problems:

Cost and scaling friction – You have to scale the network load balancer vertically as the size and throughput requirements of your Kubernetes cluster/s grows.
Operational overhead – Virtual IPs (VIPs) are often owned by another team, so simple service changes require coordination.
Stateful failure modes – Kube-proxy load balancing is stateful per node, so losing an ingress node can break active sessions.
Configuration drift – Kubernetes is declarative, but the upstream load balancer is not, which causes divergence over time.

Calico Load Balancer flips that model. Instead of dedicated hardware, it uses the Calico eBPF data plane on ordinary Linux nodes in the cluster, advertises service IPs via BGP, and makes the load balancing decision consistent across nodes. The result is a system that is cheaper to scale, easier to operate, and more resilient to node or path changes.

How Calico Load Balancer works (and why Maglev matters)

The core idea is consistent hashing. Instead of each node picking a backend at random and storing that decision in per-node state, Calico Load Balancer computes the same backend choice on any node for the same flow. This is implemented with Maglev, a consistent hashing algorithm that:

Evenly distributes connections across backends.
Minimizes disruption when load balancer nodes come and go.
Allows any load balancer node to make the same backend selection, even mid-connection.

Kube-proxy uses random selection plus per-node state, which is fine for many cases but can fail under node churn or route changes. Maglev avoids that by making the decision deterministic. Nodes may still cache the mapping for performance, but the flow-to-backend decision can be reproduced anywhere, which is what keeps sessions stable when traffic lands on a different node.

Strategic Assessment: Is This Right for Your Deployment?

Questions you can ask your team to identify if Calico Load Balancer can help your environment:

Which services are most impacted by node churn today?
Where do we see the most operational overhead in Virtual IP (VIP) provisioning?
How do we secure access to service VIPs?
Does the network have Equal Cost Multi-Path (ECMP) access to service VIPs?
How do we handle VIP failover?
Are there services with high-throughput requirements?

The Life of a Packet

A key design goal is to keep client sessions stable while enabling horizontal scale. Here is a simplified flow for a typical ECMP + BGP setup:

This diagram shows how Direct Server Return (DSR) allows the return path to bypass the load balancer node, reducing latency and hop count.

A few important details:

The top-of-rack router uses ECMP to pick a load balancer node to receive the packet.
That node runs the Maglev algorithm to choose the backend pod. It DNATs the packet and tunnels it to the node that hosts the pod.
The pod replies, and the node SNATs the packet back to the service VIP before it leaves.
With DSR (Direct Server Return), the return path bypasses the load balancer node and goes straight back to the client. The client always sees responses from the advertised service VIP.

That DSR path is important. It keeps the data path efficient and reduces load balancer hop count on the return path. It also prevents the client from seeing internal pod IPs.

DSR compared to a traditional return path

If you have only worked with classic NAT-based load balancers, DSR can feel unusual. The key difference is that the response does not have to traverse the same load balancer node that handled the inbound packet. That has two practical benefits: less work for the load balancer nodes and lower return-path latency.

Maglev and caching: deterministic and fast

There are two pieces working together in Calico Load Balancer:

The Maglev lookup table: Provides the deterministic backend choice. Any node can compute the same result for the same flow, which is why mid-connection packets can land on a different node without breaking the session.
A per-flow cache: (for example, via conntrack) can retain that decision for efficiency, and to preserve existing connections when the backend lookup table changes. It is not the source of truth for correctness.

This is a subtle but important difference from kube-proxy. In kube-proxy, the per-node conntrack decision is the only thing tying a flow to a backend. In Calico Load Balancer which uses Calico’s eBPF dataplane, the decision can be reproduced on any node, which is what makes failover or ECMP rehash events non-disruptive.

What happens during failures or path changes

Consistent hashing is not just about distribution. It is about resilience. In practice, you can test this by intentionally re-routing traffic for an existing TCP connection to a different node. Even if the new node has no prior per-flow state, it can recompute the same backend decision using Maglev, so the connection can continue without disruption.

Calico uses Maglev consistent hashing to ensure TCP sessions remain stable even if a load balancer node fails or is drained

This matters when:

A load balancer node fails or is drained.
ECMP next hops reshuffle due to network outages.
You scale the load balancer pool up or down.

Because the decision is deterministic, the packet can land on any node and still find the correct backend. The whole cluster then seemingly acts as a single, distributed load balancer, with per-node caches for additional performance and resilience.

Configuration workflow (high level)

Calico Load Balancer is configured and managed declaratively just like any other Kubernetes resource. A typical configuration flow looks like this:

Create a dedicated IP pool for Calico LB IPAM, marked for LoadBalancer use.
Create a Service of type LoadBalancer. Calico IPAM allocates a VIP from that pool.
Advertise the VIP to the upstream network using Calico BGP (optional BFD for faster detection of outages).
Ensure your upstream router uses ECMP to send traffic for the VIP to the Calico load balancer nodes.

# Calico IP pool for load balancer VIPs
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: loadbalancer-ip-pool
spec:
  cidr: 192.210.0.0/20
  blockSize: 24
  assignmentMode: Automatic
  allowedUses:
    - LoadBalancer


# Kubernetes Service using Calico LB
apiVersion: v1
kind: Service
metadata:
  name: my-app
  annotations:
    lb.projectcalico.org/external-traffic-strategy: maglev
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - port: 443
      targetPort: 8443

From there, the VIP is advertised and traffic can arrive through the ECMP paths to any load balancer node. Calico handles the rest.

Platform Benefits

The benefits discussion above can translate into real operational advantages for platform teams:

Remove Hardware Dependency: Scale load balancing capacity by adding standard Kubernetes nodes rather than purchasing expensive appliances or coordinating with vendors and avoid vendor lock-in.
Kubernetes-native approach: Reduces complexity by keeping all service configuration within your existing GitOps workflows – no separate load balancer management interfaces or external ticketing systems.
Session persistence: Addresses one of the most common causes of user-facing outages in traditional setups, where losing an ingress node would drop all active connections.
Self-service capability: Empowers development teams to provision and modify load balancer configurations without waiting for network team approvals, significantly reducing time-to-market for new services.
Predictable traffic distribution: Maglev’s consistent hashing ensures that traffic distribution remains predictable and fair even as backend pods scale up and down, preventing the “hot spot” issues that can occur with simpler load balancing algorithms.

Conclusion

Calico Load Balancer gives you a Kubernetes-native way to scale your load balancer and protect critical services without the operational drag of traditional appliances.

Ready to scale your on-prem networking?

If you want to try this in your environment, here is a safe, incremental path:

1. Identify a non-critical service that is a good LoadBalancer candidate.
2. Create a Calico IP pool for LoadBalancer VIPs and advertise it via BGP to your upstream network.
3. Enable a LoadBalancer Service with Maglev for that service and confirm the VIP is reachable.
4. Validate failover: remove a load balancer node or change ECMP next hops and verify sessions continue.
5. Document the workflow and replicate to other services.

Learn more about Calico eBPF

The post Calico Load Balancer: Simplifying Network Traffic Management with eBPF appeared first on Tigera - Creator of Calico.

Lift-and-Shift VMs to Kubernetes with Calico L2 Bridge Networks

Alister Baroi — Sat, 21 Mar 2026 06:12:02 +0000

On paper, lift-and-shift VM migration to Kubernetes sounds simple. Compute can be moved. Storage can be remapped. But many migration projects stall at the network boundary. VM workloads are often tied to IP addresses, network segments, firewall rules, and routing models that already exist in the wider environment. That is where lift-and-shift becomes much harder than it first appears.

Why lift-and-shift migration is challenging

In a traditional hypervisor environment:

A VM connects to a network the rest of the data center already understands.
Its IP address is a first-class citizen of the network.
Firewalls, routers, monitoring tools, and peer applications know how to reach it.
Existing application dependencies are often built around that network identity.

Default Kubernetes pod networking works very differently:

Pod IPs usually come from a cluster-managed pod CIDR.
Those IPs are mainly meaningful inside the Kubernetes cluster.
The upstream network usually does not have direct visibility into pod networks.
The original network segments from the VM world are not preserved by default.

This creates a major problem for VM migration:

The workload can no longer keep the same network presence it had before.
Teams often need to introduce VIPs or reconfigure the networking settings of the VM.
That adds more complexity since changing the IP of the VM also requires changes to network firewall and load balancer configuration.
At scale, it can make migration slower, more expensive, and harder to justify.

So while Kubernetes can be a strong platform for running VM workloads, default pod networking is often not a natural fit for lift-and-shift migration. The networking gap is one of the biggest reasons these projects become more complex than expected.

The lack of network continuity is shown in the image below.

Default pod networking often creates a gap in network continuity, forcing complex reconfigurations and breaking existing dependencies like firewalls and load balancers.

Introducing Calico L2 Bridge Networks

Calico L2 Bridge Networks are designed to close that gap. Instead of forcing the VM to adapt to the Kubernetes pod network, Calico allows administrators to extend the existing layer 2 network all the way to the virtual machine running in Kubernetes.

Administrators can define a network resource in Kubernetes, and Calico creates a bridge on the cluster nodes to extend external networks. A trunk interface can be attached to the bridge, allowing VLANs to be carried all the way to the virtual machine. During migration, the migration tool can map the VM’s existing interface to interface definitions in the cluster and also inform Calico of the VM’s IP address, so Calico can keep track of that address throughout the VM’s lifecycle. Calico does all the underlying plumbing to ensure that the VM retains its network connectivity after migration.

The key point is that the VM does not need a brand new networking model just because it moved to Kubernetes. The same layer 2 network structure can be preserved, which makes lift-and-shift migration much more practical.

Why this matters

Existing VLAN-based connectivity can be extended directly to the VM.
Administrators do not need to re-address the VM or place it behind VIPs just to make migration work.
Multiple VLANs can be supported through the same trunk-backed bridge.
The network can move with the VM, instead of becoming a separate redesign project.

The network continuity offered by Calico L2 Bridge Networks is shown in the image below.

Calico L2 Bridge Networks allow you to extend existing Layer 2 infrastructure directly into Kubernetes, enabling “lift-and-shift” migrations that preserve original IP addresses and VLANs.

Readiness Assessment: Is L2 Bridge Networking Right for Your Migration?

Ask your infrastructure and networking teams:

Do our existing VMs rely on specific VLAN tags for firewall policy enforcement?
Will re-addressing our workloads require updating multiple external load balancers or hardcoded application dependencies?
Do we need to maintain L2 adjacency between our legacy VM clusters and new Kubernetes nodes during a phased migration?
Is network observability (via eBPF) a requirement for our compliance or troubleshooting workflows post-migration?

Benefits After Migration

Calico L2 Bridge Networks do more than simplify the move into Kubernetes. Once the VM is running in Kubernetes, Calico can also bring the same operational advantages that teams already expect for cloud-native workloads.

Network Observability

One major benefit is observability. Calico provides visibility into network traffic for these VM interfaces, giving administrators a much clearer view of how workloads are communicating after migration. Because Calico uses eBPF, it can capture deep insights into network behavior without relying on external tooling or guesswork. That makes it easier to understand traffic patterns, troubleshoot issues, and operate migrated VMs with more confidence.

Calico Policy Enforcement

Another major benefit is policy enforcement. Administrators can apply declarative network policy directly to these VM interfaces using Kubernetes-native constructs. Policies can be based on labels, which fits naturally into Kubernetes operations, and selectors can be used to target specific VLANs or external networks when defining policy. Teams can also migrate networking policy from their previous hypervisor environment into Calico network policy, helping them maintain the same security posture as workloads move into Kubernetes. In practice, that means teams can preserve the connectivity model they need while still applying consistent, modern security controls to VM workloads inside Kubernetes.

Live Migration

Live migration is another important benefit. Once the VM is running in Kubernetes, it can be moved from one node to another while retaining the same network configuration. That is critical for day-2 operations, because it means teams can take advantage of Kubernetes-based VM mobility without having to rework network settings each time a workload moves. The network identity stays consistent even as the VM is migrated across the cluster.

By decoupling compute and networking, Calico ensures that migrated VMs can move between cluster nodes while retaining their original network configuration and identity.

Conclusion

Lift-and-shift VM migration to Kubernetes often breaks down because the network model does not move with the workload. That forces teams to introduce workarounds such as VIPs, re-addressing, and additional operational complexity, which can quickly turn a simple migration plan into a much larger project.

Calico L2 Bridge Networks help remove that barrier by extending existing layer 2 networks all the way to the VM inside Kubernetes. That means teams can preserve familiar network configurations during migration while also gaining the advantages of running VMs on Kubernetes, including observability, declarative policy, and live migration. Instead of treating networking as a migration blocker, organizations can use Calico to make it part of a cleaner and more practical path forward.

Webinar Recording

Available on demand

Calico L2 bridge networking for virtual machines

Migrating VMs to Kubernetes? Learn how to preserve your existing IPs, VLANs, and security policies — no network rebuild required.

“Lift and shift” VM migrations with zero IP changes

Maintain existing VLANs and security dependencies

Expert guidance from Tigera’s networking team

Watch the recording

The post Lift-and-Shift VMs to Kubernetes with Calico L2 Bridge Networks appeared first on Tigera - Creator of Calico.

AI Assistant for Calico: Troubleshooting at the Speed of Thought

Alister Baroi — Thu, 19 Mar 2026 20:36:45 +0000

Despite the wealth of data available, distilling a coherent narrative from a Kubernetes cluster remains a challenge for modern infrastructure teams. Even with powerful visualization tools like the Policy Board, Service Graph, and specialized dashboards, users often find themselves spending significant time piecing together context across different screens. Making good use of this data to secure a cluster or troubleshoot an issue becomes nearly impossible when it requires manually searching across multiple sources to find a single “connecting thread.”

Inevitably, security holes happen, configurations conflict causing outages, and teams scramble to find that needle-in-the-haystack cause of cluster instability. A new approach is needed to understand the complex layers of security and the interconnected relationships among numerous microservices. Observability tools need to not only organize and present data in a coherent manner but proactively help to filter and interpret it, cutting through the noise to get to the heart of an issue. As we discussed in our 2026 outlook on the rise of AI agents, this represents a fundamental shift in Kubernetes management.

Key Insight: With AI Assistant for Calico, observability takes a leap forward, providing a proactive, conversational, and context-aware intelligence layer to extract actionable insights from a sea of raw telemetry. SREs can interrogate their data through a natural language interface instead of having to painstakingly construct complex queries, removing knowledge barriers and reducing MTTR (Mean Time to Repair).

Beyond Manual Log Analysis

To understand the impact of the AI Assistant for Calico, it is helpful to look at the traditional workflow through the lens of the challenges platform teams face daily. Troubleshooting connectivity issues, for example, typically starts with a look at traffic flows, identifying ones that may be problematic, then drilling down into the details while looking up possibly relevant policies, network configuration, ingress rules, and hostname resolution in different dashboards and sets of logs. Often one or more multi-step queries have to be run and then the results have to be filtered to start getting an idea of what may be going wrong. This is particularly difficult when Kubernetes flat networks fail at scale, increasing the complexity of every query.

This sort of manual navigation slows down problem resolution and imposes a high cognitive cost on SREs. Even for seasoned engineers, debugging can take hours or even days when the answer must be excavated from multiple sources of information.

Natural Language Insights

The AI Assistant for Calico resolves these bottlenecks by replacing cumbersome queries with a seamless, natural-language interface that interprets telemetry instead of just displaying it and synthesizes data from multiple sources so you don’t have to. By moving away from rigid query languages, the assistant changes how engineers interact with their cluster data in three primary ways:

Ask, Don’t Query: Troubleshooting now starts with an articulation of intent instead of a lengthy session wrestling with search fields and operators. Being able to simply ask “What are the unrestricted egress destinations currently receiving traffic from my pods?” without painstakingly cobbling together and testing a multi-layered query is a paradigm shift. It moves the engineer’s focus from the mechanics of the search to the logic of the solution.
Context-Aware Explanations: The assistant doesn’t just return raw data; it provides summaries and recommendations generated from real telemetry and policy context. It can explain, for instance, that “Traffic is denied because policy X in namespace Y blocks TCP 443.” It also suggests further troubleshooting steps and offers remediation advice.
Unified Visibility Across the Cluster: The assistant provides insights across clusters, namespaces, and workloads, extracting details that would previously require drilling down into, for example, a specific flow or policy configuration. All of a sudden, that “connecting thread” between seemingly isolated events becomes a lot clearer.

AI Assistant for Calico allows engineers to quickly zero in on relevant information using a conversational form of root-cause analysis that even junior members of the team can have success with.

AI Assistant for Calico can quickly get you the information you need

Proactive Security and Policy Optimization

While reactive troubleshooting is critical, the AI Assistant for Calico also enables a proactive security posture by identifying misconfigurations and security gaps that might otherwise go unnoticed:

- Surfacing Exposure Risks: The AI Assistant can identify workloads exposed to the internet or detect egress exposure risks, such as pods communicating with unrestricted external destinations.
- Policy Recommendations and Generation: Instead of starting from scratch, users can ask the AI to recommend a base policy or generate a specific snippet, such as a policy to block all egress traffic from a specific training pod.
- Cleaning up the Mesh: The assistant helps maintain cluster stability and security hygiene by detecting unused or missing network policies.
- Identifying Gaps: It proactively surfaces network flows that have no policies applied to them, ensuring that the principle of least privilege is maintained across the cluster—a key requirement highlighted in the 2025 GigaOm Radar for Container Networking.

These capabilities streamline the time-consuming and error-prone process of manually managing intricate policy syntax, making for more stable, performant, and secure clusters.

Real-World Scenario: Rapidly Resolving a Blocked Service Connection

To see the impact of these capabilities, consider a common high-pressure situation for a platform engineer. An engineer receives an urgent alert that a critical production service is unable to communicate with its database.

In a traditional environment, the engineer would spend 30 to 60 minutes manually checking network policies, inspecting flow logs, and verifying namespace labels across multiple clusters to find the culprit. Every minute of manual investigation increases the risk of service downtime and customer frustration.

The AI Solution: Instead of manual log diving, the engineer asks the AI Assistant for Calico a direct question: “Why is the frontend-service in the production namespace unable to reach the db-service?”. The AI instantly analyzes the environment and identifies that a recent policy update is missing a necessary egress rule for the specific database port. Total resolution time is reduced from over an hour to just a few minutes.

Thinking ahead, the engineer asks for an audit of all staged policies. AI Assistant for Calico finds another incorrect policy—this one with a misspelled label selector—averting a future outage.

View Interactive Demo: Exploring Assistant for Calico →

A New Standard for Platform Operations

The introduction of the AI Assistant for Calico in the Winter 2026 release is the next step in observability and Kubernetes management. By adding the ability to interrogate a cluster in plain English, Calico’s unified platform bridges the gap between high-fidelity telemetry data and practical solutions

Beyond the immediate operational gains, this AI-powered approach fits into a broader strategy of defense in depth and operational simplicity, specifically regarding ingress security for AI workloads. It removes the friction of complex debugging, accelerates onboarding for new team members, and ensures that your security posture remains consistent even as your architecture scales.

Experience the Power of AI Assistant for Calico

Ready to see how AI can accelerate your Kubernetes troubleshooting and network policy management?

Watch the On-Demand Demo

Sign Up for Calico Cloud (Free Trial)

The post AI Assistant for Calico: Troubleshooting at the Speed of Thought appeared first on Tigera - Creator of Calico.

What Your EKS Flow Logs Aren’t Telling You

Alister Baroi — Wed, 18 Mar 2026 21:06:48 +0000

If you’re running workloads on Amazon EKS, there’s a good chance you already have some form of network observability in place. VPC Flow Logs have been a staple of AWS networking for years, and AWS has since introduced Container Network Observability, a newer set of capabilities built on Amazon CloudWatch Network Flow Monitor, that adds pod-level visibility and a service map directly in the EKS console.

It’s a reasonable assumption that between these tools, you have solid visibility into what’s happening on your cluster’s network. But for teams focused on Kubernetes security and policy enforcement, there’s a significant gap — and it’s not the one you might expect.

In this post, we’ll break down exactly what EKS native observability gives you, where it falls short for security-focused use cases, and what Calico’s observability tools, Goldmane and Whisker, provide that you simply cannot get from AWS alone.

What EKS Gives You Out of the Box

AWS offers two main sources of network observability for EKS clusters:

VPC Flow Logs capture IP traffic at the network interface level across your VPC. For each flow, you get source and destination IP addresses, ports, protocol, and whether traffic was accepted or rejected at the VPC level, by security groups and network ACLs. Useful for infrastructure-level visibility, but with no awareness of the Kubernetes layer.

Container Network Observability, introduced more recently and powered by Amazon CloudWatch Network Flow Monitor, goes meaningfully further. Once you’ve installed the NFM agent as a DaemonSet and configured the required IAM permissions, Scope, and Monitor resources, you get access to:

Performance metrics — pod and node-level metrics including ingress/egress flow counts, packet counts, bytes transferred, and bandwidth limit events, exposed in OpenMetrics format and scrapable by Prometheus
A service map — a visualization of traffic between pods and deployments in the EKS console, showing retransmissions, retransmission timeouts, and data transferred between communicating workloads
A flow table — a breakdown of top-talking workloads across three views: within the cluster (east-west), to AWS services (S3, DynamoDB), and to external destinations

This is a genuinely capable performance observability tool. If your primary concern is understanding network throughput, identifying bandwidth hotspots, tracking cross-AZ traffic costs, or detecting retransmission anomalies, Container Network Observability gives you a solid foundation.

But if your primary concern is Kubernetes network security, specifically understanding policy behavior, debugging denied connections, and moving toward a least-privilege posture, it leaves critical gaps.

What EKS Native Observability Doesn’t Tell You

Understanding what EKS observability doesn’t show you is just as important as knowing what it does. Several gaps become significant once you’re actively managing network policies or investigating a security incident.

No policy verdict context. This is the most important gap. Neither VPC Flow Logs nor Container Network Observability have any awareness of Kubernetes network policies. If a Calico policy is denying traffic between two pods, you will not see that denial in AWS observability tooling. You’ll see a connection failing with no indication of which policy rule fired, which tier it belonged to, or whether the traffic was intentionally blocked or the result of a misconfiguration. For teams actively managing network policies, this makes AWS observability tools nearly useless for the most common debugging scenario you’ll face.

Performance metrics, not security metrics. The flow-level metrics in Container Network Observability (retransmissions, retransmission timeouts, and bytes transferred) are designed to answer performance questions. They are not designed to answer security questions like: which namespaces are communicating that shouldn’t be, which egress destinations are being reached, or which policy rules are being evaluated for a given flow. These are fundamentally different observability needs, and AWS’s tooling is built for the former.

Top 500 flows only, over a 1-hour window. The NFM agent collects the top 500 network flows by volume every 30 seconds, and the console visualizations are scoped to a 1-hour time range. For security investigations, this matters: less frequent or lower-volume connections — exactly the kind that might indicate lateral movement or exfiltration — may not appear in the top 500 and will be invisible to the service map and flow table.

No namespace-level policy context. While the service map does show pod and deployment-level topology, it shows you traffic volume and performance — not whether that traffic is authorized by your network policies, which policies evaluated it, or whether any of it should be blocked. Understanding the security posture of your namespace boundaries requires a different layer of data entirely.

Setup complexity. Enabling Container Network Observability requires installing the NFM agent add-on, configuring IAM permissions with Pod Identity or IRSA, and creating NFM Scope and Monitor resources either through the console, AWS CLI, or Terraform. For teams managing this with IaC, that means defining additional resource dependencies and managing the Terraform AWS Provider version requirements. It’s not prohibitively complex, but it’s meaningful infrastructure to own and maintain.

What Calico Adds: Goldmane and Whisker

Calico’s observability capabilities are built on two components introduced in Calico 3.30: Goldmane, a flow log API that generates enriched, Kubernetes-native flow data, and Whisker, a web-based UI for visualizing and filtering that data in real time. Together they give you a fundamentally different class of observability — one built specifically for the Kubernetes security layer.

Goldmane: Flow Logs That Speak Kubernetes Security

Where AWS Container Network Observability speaks in performance metrics, Goldmane speaks in Kubernetes policy context. Every flow log entry generated by Goldmane includes:

Source and destination namespace, pod name, and deployment — Kubernetes identity is always present, regardless of IP churn
Service names — traffic is attributed to the service it passed through, not just the backend pod IP
Policy verdicts — each flow includes which Calico policy rule evaluated it, whether the action was Allow or Deny, and which tier the policy belonged to
Port, protocol, and domain information — including DNS-based destinations for egress traffic

The policy verdict data is what changes the debugging experience most fundamentally. When a network policy misconfiguration breaks Prometheus scraping, blocks a health check probe, or silently drops traffic between namespaces — scenarios that are routine for any team actively managing network policies — Goldmane tells you exactly which rule fired and why. You’re not correlating IP addresses and timestamps across multiple tools; the answer is in the flow log.

Goldmane exposes its data via a gRPC API, making it straightforward to consume from your existing observability stack, whether that’s Elasticsearch, Grafana, or a custom pipeline. It covers all flows in your cluster, not just the top 500 by volume.

Whisker: Real-Time Policy Visibility Without Additional Infrastructure

Whisker is a lightweight web console that surfaces Goldmane’s flow data without requiring any additional tooling. You can filter flows by namespace, pod, policy verdict, or direction, and see in real time which traffic is being allowed and denied across your cluster.

For teams moving from a default-allow posture toward namespace isolation or zero trust, Whisker is particularly valuable during the transition: you can watch policy verdicts update live as you apply and adjust rules, rather than inferring policy behavior from downstream signals like application errors and health check failures.

Whisker is included in Calico Open Source as of 3.30. Access it via a local port-forward — no agent DaemonSet configuration, no IAM policies, no cloud service dependencies required.

Going Further: Calico Cloud Free Tier

Goldmane and Whisker give you a significantly richer observability foundation for security and troubleshooting than AWS native tooling. If you want to go further, Calico Cloud’s free tier adds a hosted experience that requires no additional infrastructure to operate.

The Calico Cloud Service Graph provides a live, visual map of communication between namespaces, services, and pods.

Connecting your EKS cluster to Calico Cloud gives you access to the Service Graph, which provides a live visual map of how your namespaces, services, and pods are communicating, overlaid with Calico policy evaluation data. Unlike the AWS console service map, which surfaces performance metrics for your top flows, the Calico Cloud Service Graph shows you the security posture of your traffic: which connections are authorized, which are being denied, and where your policy coverage has gaps. Teams that see it for the first time consistently describe it as the moment their cluster’s network finally became legible from a security perspective.

The free tier also includes the policy recommendation engine, which analyzes your cluster’s actual traffic patterns and automatically generates staged network policies to implement namespace isolation. Staged policies let you audit the recommended rules and see exactly which traffic they would allow and deny before you enforce them. It’s the fastest path from a default-allow EKS cluster to one where every namespace is isolated and secured.

Calico Cloud’s free tier is genuinely free, with no sales engagement required. It supports a single cluster with 24-hour data retention — enough to experience the Service Graph and understand what your cluster’s traffic actually looks like from a security perspective.

A Quick Comparison

Feature	VPC Flow Logs	EKS Container Network Observability	Calico Open Source (Goldmane + Whisker)	Calico Cloud Free Tier
Pod / namespace identity	✗	✓
(deployment/pod view)	✓	✓
Service-level visibility	✗	✓
(service map)	✓	✓
Network performance metrics	Partial	✓
(RT, RTO, bytes)	✗	✗
Calico policy verdict (allow/deny + which rule)	✗	✗	✓	✓
All flows (not just top N by volume)	✓	✗
(top 500)	✓	✓
Security posture / policy gap visibility	✗	✗	✓	✓
Real-time policy visualization	✗	✗	✓
(Whisker)	✓
(Service Graph)
Policy recommendations	✗	✗	✗	✓
Setup complexity	Low	Medium
(NFM agent, IAM)	Low
(port-forward)	Low
(single manifest)

Sign up for the free tier

Goldmane and Whisker, available today in Calico 3.30+, fill the gaps in EKS observability. They’re purpose-built for the Kubernetes security layer and give every EKS operator richer policy-level observability at no cost.

If you want to go further and have a live service graph that surfaces policy context, hosted dashboards, and automated policy recommendations, Calico Cloud’s free tier is the next step.

Conclusion

AWS Container Network Observability is a meaningful improvement over VPC Flow Logs and a genuinely useful tool for understanding network performance in your EKS environment. If you’re tracking retransmissions, monitoring cross-AZ traffic, or trying to identify bandwidth hotspots, it’s worth enabling.

But it was designed for performance observability, not security observability. It has no awareness of Kubernetes network policy behavior, no policy verdict data, and no visibility into whether your namespace boundaries are being respected. For teams actively managing network policies or trying to move toward a least-privilege security posture, these are not minor gaps.

Goldmane and Whisker, available today in Calico 3.30+, fill exactly those gaps. They’re purpose-built for the Kubernetes security layer and give every EKS operator richer policy-level observability at no cost. If you want to go further and have a live service graph that surfaces policy context, hosted dashboards, and automated policy recommendations, Calico Cloud’s free tier is the next step.

The post What Your EKS Flow Logs Aren’t Telling You appeared first on Tigera - Creator of Calico.