Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

As part of our work at Tigera building products that create secure runtime environments for enterprise agents at scale in the real world, one small part of this puzzle I think about a lot is policy, and runtime enforcement of policy, and how to create a comprehensive secure runtime, configured from one place.

Practically no one runs a single Kubernetes cluster in production these days. Maybe that’s how it started but data sovereignty requirements, acquisitions, AI initiatives and the need for edge servers, among other considerations, have pulled most enterprises into multi-cluster territory whether they planned for it or not.

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.

The Calico community moves fast. With the releases of Calico 3.30 and 3.31, brings improvements in scalability, network security, and visibility. Now, we want to see what YOU can do with them! We’re excited to officially invite you to the Project Calico 3.30+ Community Hackathon. Whether you’re a seasoned eBPF expert or a newcomer to the Gateway API, we welcome your innovation and your ideas!

Kubernetes networking offers incredible power, but scaling that power often transforms a clean architecture into a tangled web of complexity. Managing traffic flow between hundreds of microservices across dozens of namespaces presents a challenge that touches every layer of the organization, from engineers debugging connections to the architects designing for compliance. The solution to these diverging challenges lies in bringing structure and validation to standard Kubernetes networking.

For years, AI and machine learning workloads lived in the lab. They ran as internal experiments, batch jobs in isolated clusters, or offline data pipelines. Security focused on internal access controls and protecting the data perimeter. That model no longer holds. Today, AI models are increasingly part of production traffic, which is driving new challenges around securing AI workloads in Kubernetes.

Encrypting internal traffic and enforcing mutual (mTLS), a form of TLS in which both the client and server authenticate each other using X.509 certificates., has transitioned from a “nice-to-have” to a hard requirement, especially in Kubernetes environments where everything can talk to everything else by default.

Platform teams are tasked with keeping clusters secure and observable while navigating a skills gap. At KubeCon + CloudNativeCon North America, The New Stack spoke with Ratan Tipirneni, President and CEO of Tigera, about the future of Kubernetes security, AI-driven operations, and emerging trends in enterprise networking. The highlights from that discussion are summarized below.

The Kubernetes community recently announced that Ingress NGINX, one of the most widely used Ingress controllers, will be retired. This change means teams need to plan for a secure, modern, and future-proof alternative for managing Kubernetes traffic. The Kubernetes SIG Network and the Security Response Committee confirmed that the project will only receive basic maintenance until March 2026. After that, there will be no new releases, bug fixes, or security updates.

If you’ve managed traffic in Kubernetes, you’ve likely navigated the world of Ingress controllers. For years, Ingress has been the standard way of getting our HTTP/S services exposed. But let’s be honest, it often felt like a compromise. We wrestled with controller-specific annotations to unlock critical features, blurred the lines between infrastructure and application concerns, and sometimes wished for richer protocol support or a more standardized approach.