Learn Kata Containers - Network Security & Policy

#Introduction

In episode 7 we saw how a microVM has its own network. Episode 14 asks the security question: who is allowed to talk to whom? MicroVM isolation limits what tenants can see of each other at the kernel level — but applications can still connect to each other over the network. Confusing the two is a common mistake you must avoid.

Network policy and mTLS operate on top of microVM isolation: the microVM provides runtime isolation, policy provides communication control, and mTLS provides data confidentiality in transit. The three work together to form layered defense.

#NetworkPolicy with CNI

#NetworkPolicy Basics

NetworkPolicy is a Kubernetes object that controls communication between pods. It works with label selectors: which pods may receive/send from/to which pods, on which ports. The implementation is provided by the CNI — so the CNI choice determines how fully NetworkPolicy is supported.

Example policy: only the frontend pod may access the api pod, and only through port 8080:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

podSelector with app: api determines the target pod, and the ingress block restricts who may enter. This policy works identically for Kata pods and runc pods — the CNI doesn't distinguish between the two at the network level.

#Why Policy Is Still Needed

MicroVM isolation doesn't enforce policy automatically. A Kata pod on node A can still talk to a Kata pod on node B if the CNI allows it. Runtime isolation ≠ network isolation. This is a frequently misunderstood point: you use Kata for host isolation, but you still need policy for communication control.

Remember from episode 7: CNI runs normally for Kata pods. So standard NetworkPolicy applies as usual — without special changes. This is a big advantage of Kata's Kubernetes integration.

#Egress Filtering

Ingress policy restricts what comes in; egress restricts what goes out. For untrusted workloads (a recurring theme in this series), egress filtering is crucial: even if a microVM is compromised, its outgoing traffic is limited.

Example: the sandbox pod may only access certain registries and CoreDNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sandbox-egress
spec:
  podSelector:
    matchLabels:
      app: sandbox
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
    - to:
        - ipBlock:
            cidr: 10.0.0.0/16
      ports:
        - protocol: TCP
          port: 443

The first egress block allows DNS to kube-system, the second allows HTTPS to a specific CIDR. All other outgoing traffic is blocked. For sandboxes executing unknown code, egress filtering is the most valuable control — it limits the "reach" of a compromise.

#Pod Identity

Label-based NetworkPolicy is strong, but labels can be spoofed in some cases. A stronger solution comes from workload identity: an approach that derives identity from verified labels rather than IP addresses. Various modern CNIs (including eBPF-based ones) support such identity — policies are written against identity, so they stay valid even when pod IPs change.

For Kata pods, identity works as usual: the pod is treated as a standard Kubernetes workload, and the CNI assigns identity based on its labels. MicroVM isolation doesn't interfere with this mechanism.

The interesting consequence: the combination of identity + microVM gives two layers of defense. Identity prevents spoofing at the network level; the microVM prevents tenants from breaking into the node. This is the pattern production deployments use for untrusted workloads.

#Data-in-Transit: mTLS with Service Mesh

#Why mTLS for MicroVMs

Egress filtering limits where traffic can go, but doesn't secure the content of traffic on the network. For workloads processing sensitive data, communication between pods must be encrypted and authenticated. This is where mTLS (mutual TLS) comes in — usually via a service mesh like Istio or Cilium Service Mesh.

mTLS means both parties prove their identity to each other through certificates, and all traffic is encrypted. Unlike regular TLS (which only authenticates the server), mTLS authenticates both — suitable for service-to-service communication.

#Service Mesh on Top of Kata

A service mesh works at the workload level — usually with a sidecar proxy next to the application container. Kata pods can use sidecars: the sidecar container lives in the same microVM as the application container (remember episode 4: one pod = one microVM).

The flow stays the same: the application talks to the sidecar on localhost, and the sidecar performs mTLS to the destination sidecar. Because all containers in a pod share the microVM, the sidecar and application communicate over the guest's loopback network — no external network overhead between them.

Enabling mTLS via Istio for a specific namespace:

kubectl label namespace kata-prod istio-injection=enabled
kubectl get pods -n kata-prod

kubectl label namespace kata-prod istio-injection=enabled tells Istio to inject sidecars into new pods in that namespace. Kata pods will receive the sidecar like regular pods — seamless integration.

#Verifying Encrypted Traffic

From inside the guest, you can verify that outgoing traffic is encrypted by looking at the sidecar process:

kata-runtime list
sudo kata-runtime exec <sandbox-id> ps aux | grep -i envoy

kata-runtime exec <sandbox-id> ps aux | grep -i envoy shows the Envoy process (Istio's proxy) running inside the microVM — proof that mTLS is managed from within the guest, and outgoing microVM traffic is already encrypted.

#Conclusion

What you should take away:

• NetworkPolicy works normally for Kata pods — runtime isolation ≠ network isolation.
• Egress filtering limits the reach of a compromise for untrusted workloads.
• Pod identity adds an anti-spoofing layer on top of microVM isolation.
• mTLS service mesh encrypts and authenticates traffic between pods.
• The sidecar runs inside the same microVM as the application.
• Layered defense: microVM + policy + mTLS.

In the next episode, episode 15, we'll cover secure boot & image trust — verifying the guest kernel with signatures, image attestation, image signing, SBOM, and admission policy with Kyverno/OPA for Kata workloads. The supply chain is the attack entry point most often forgotten.