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.

Running one Kubernetes cluster is complex enough. Running five across AWS, GCP, and an on-prem data center without a unified control plane gets painful fast. Kubernetes Federation v2 (KubeFed) was built to solve this problem: managing federated Kubernetes clusters from a single point of control and distributing workloads across regions and providers without duplicating YAML files for every environment.

An AI agent moving laterally through a Kubernetes cluster does not look like an intrusion. There is no foreign process, no exploit, no dropped binary — just the agent using the identity, network routes, and tools it was handed at deployment to reach targets it was technically allowed to touch. That is the entire problem. The controls you run were built to catch an outsider pivoting from host to host.

A few weeks ago I was on a call with a financial services customer who had moved a credit-decisioning model into production on Red Hat OpenShift AI. They were happy with the platform. They were less happy with the answer they had for a question their risk officer had just asked: “If an attacker encrypts the cluster tomorrow, what do we need to bring back to be inference-ready by Monday morning?” The team started listing the obvious things — the model artifact, the serving endpoint.

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.

Our previous post, How to Secure Microservices with SPIFFE and Istio, showed how to secure Kubernetes microservices using Istio policy and SPIFFE identities, with Teleport issuing the identities that the mesh trusts. The question teams face next is: How do you extend that identity-driven security model to workloads outside Kubernetes — such as VMs, edge gateways, and legacy services — without creating a massive certificate-management project?

A single leaked Kubernetes credential rarely stays in the cluster. It opens the registry credentials, private Docker images, and private GitHub repositories behind it. In Q1 2026 alone, our detectors caught close to 2,000 new such leaks on GitHub, 28% valid at leak time.