Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

Calico has used eBPF as one of its dataplanes since version 3.13, released more than five years ago. At the time, this was an exciting step forward, introducing a new, innovative data plane that quickly gained traction within the Calico community. Since then, there have been many changes and continued evolution, all thanks to the many adopters of the then-new data plane.

Kubernetes adoption is growing, and managing secure and efficient network communication is becoming increasingly complex. With this growth, organizations need to enforce network policies with greater precision and care. However, implementing these policies without disrupting operations can be challenging. That’s where Calico Whisker comes in. It helps teams implement network policies that follow the principle of least privilege, ensuring workloads communicate only as intended.

Securing what comes into your Kubernetes cluster often gets top billing. But what leaves your cluster, outbound or egress traffic, can be just as risky. A single compromised pod can exfiltrate data, connect to malicious servers, or propagate threats across your network. Without proper egress controls, workloads can reach untrusted destinations, creating serious security and compliance risks.

As organizations expand Kubernetes adoption—modernizing legacy applications on VMs and bare metal, running next-generation AI workloads, and deploying intelligence at the edge—the demand for infrastructure that is scalable, flexible, resilient, secure, and performant has never been greater. At the same time, compliance, consistent visibility, and efficient management without overburdening teams remain critical.

The AI revolution is here, and it’s running on Kubernetes. From fraud detection systems to generative AI platforms, AI-powered applications are no longer experimental projects; they’re mission-critical infrastructure. But with great power comes great responsibility, and for Kubernetes platform teams, that means rethinking security.

A single cyberattack or system outage can threaten not just one financial institution, but the stability of a vast portion of the entire financial sector. For today’s financial enterprises, securing dynamic infrastructure like Kubernetes is a core operational and regulatory challenge. The solution lies in achieving DORA compliance for Kubernetes, which transforms your cloud-native infrastructure into a resilient, compliant, and secure backbone for critical financial services.

When Kubernetes workloads need to connect to the outside world, whether to access external APIs, integrate with external systems, or connect to partner networks, they often face a unique challenge. The problem? Pod IP addresses inside Kubernetes clusters are dynamic and non-routable. For external systems to recognize and trust this traffic, workloads need a consistent, dependable identity. This means outbound connections require fixed, routable IP addresses that external services can rely on.