Author Archives: Peter Kelly
Author Archives: Peter Kelly
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. The more companies we talk to trying to lock down and secure these platforms at runtime, the more I believe AI Agent security needs policy in multiple places, not just one (e.g., not just at the gateway layer), and ideally expressed in the same policy language.
At the L7 gateway layer, every agent call is observable: who is calling, what they are calling, what attributes both sides carry, what the requested action is. This is where you decide whether an agent should be permitted to talk to a particular MCP server, invoke a particular tool, delegate to another agent, or call a particular LLM. The atoms of policy here are identity, action, resource, and context.
At the agent runtime layer, or kernel layer in a container, what the agent does inside its own runtime is observable: syscalls, file access, library loads, network connections that bypass Continue reading
Today, organizations struggle managing disparate technologies for their Kubernetes networking and network security needs. Leveraging multiple technologies for networking and security for in-cluster, ingress, egress, and traffic across clusters creates challenges, including operational complexities and increased costs. For example, to manage ingress traffic for Kubernetes clusters, users cobble together multiple solutions from different providers such as ingress controllers or gateways and load balancers for routing traffic, as well as Web Application Firewalls (WAFs) for enhanced security.
Despite the challenges it brings, deploying disparate technologies has been a “necessary evil” for organizations to get all the capabilities needed for holistic Kubernetes networking. Here, we’ll explore challenges this proliferation of tooling introduces, and provide actionable tips for today’s platform and security teams to overcome these issues.
The fragmented approach to networking and network security in Kubernetes leads to challenges and inefficiencies, including:
Last June, Tigera announced a first for Kubernetes: supporting open-source WireGuard for encrypting data in transit within your cluster. We never like to sit still, so we have been working hard on some exciting new features for this technology, the first of which is support for WireGuard on AKS using the Azure CNI.
First a short recap about what WireGuard is, and how we use it in Calico.
WireGuard is a VPN technology available in the Linux kernel since version 5.6 and is positioned as an alternative to IPsec and OpenVPN. It aims to be faster, simpler, leaner and more useful. This is manifested in WireGuard taking an opinionated stance on the configurability of supported ciphers and algorithms to reduce the attack surface and auditability of the technology. It is simple to configure with standard Linux networking commands, and it is only approximately 4,000 lines of code, making it easy to read, understand, and audit.
While WireGuard is a VPN technology and is typically thought of as client/server, it can be configured and used equally effectively in a peer-to-peer mesh architecture, which is how we designed our solution at Tigera to work in Kubernetes. Using Calico, Continue reading