Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

As Kubernetes clusters scale from a few development sandboxes to massive, multi-tenant production environments, platform teams often find themselves facing a configuration management crisis. A small number of microservices suddenly demand hundreds of individual Kubernetes NetworkPolicy objects. Managing them becomes operationally expensive, auditing them is difficult, and a single developer misconfiguration can easily drop critical production traffic or open a massive security hole.

In Part 1 of this series, we addressed 18 Kubernetes best practices spanning across container hardening, observability, availability, and fault tolerance. Those practices secure the containers that agents run in. But the CNCF AI Technical Community Group's cloud-native agentic standards go further, establishing that securing containers is only the beginning.

TL;DR: Aikido now supports Docker Hardened Images. A scan that used to return hundreds of CVEs collapses to the handful that actually apply, because Docker's VEX attestations filter out everything they've verified as non-exploitable. Zero additional setup. Container security has a noise problem You scan a container image and get back a list of 50, 100, sometimes hundreds of CVEs. You open a few. Some look scary. Most are irrelevant. Some have already been patched by the image maintainer.

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?