🚪 Egress Controls — Locking Down Outbound Traffic

Ingress controls (NetworkPolicy, Ingress/Gateway) are well understood, but egress is often overlooked. An attacker who compromises a pod needs to exfiltrate data or beacon to a C2 server — both require outbound connectivity. Controlling egress limits what a compromised workload can do.

Layer 1: NetworkPolicy Egress Rules

The simplest egress control — already covered in the networking chapter, but worth a reminder in the security context. A default-deny egress policy:

# Default-deny all egress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Egress]

---
# Allow only DNS + specific external CIDR
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payments-allowed-egress
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
  - ports:                    # allow DNS
    - port: 53
      protocol: UDP
  - to:                       # allow stripe API
    - ipBlock:
        cidr: 54.187.174.169/32
    ports:
    - port: 443

Layer 2: Istio Egress Gateway

Istio provides an Egress Gateway — a dedicated Envoy proxy that all outbound traffic is forced through. You can then apply fine-grained L7 rules, TLS origination, and audit logging:

# Define an external service
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: stripe-api
spec:
  hosts: [api.stripe.com]
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS
  location: MESH_EXTERNAL

---
# Block all other external traffic via Sidecar resource
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: restrict-egress
  namespace: payments
spec:
  egress:
  - hosts:
    - "payments/*"         # own namespace services
    - "istio-system/*"     # telemetry
    - "./stripe-api"       # external Stripe only

Layer 3: Cilium FQDN-Based Egress Policy

Cilium's DNS-aware network policies allow egress rules based on fully-qualified domain names — much more practical than managing IP CIDRs for external APIs:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: payments-fqdn-egress
  namespace: payments
spec:
  endpointSelector:
    matchLabels:
      app: payment-processor
  egress:
  - toFQDNs:
    - matchName: "api.stripe.com"
    - matchPattern: "*.stripe.com"
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP
  - toEndpoints:               # allow kube-dns
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s:k8s-app: kube-dns

Egress Controls Comparison

🪪 SPIFFE & SPIRE — Workload Identity

SPIFFE (Secure Production Identity Framework For Everyone) is a CNCF standard that defines how workloads prove their identity using short-lived X.509 certificates called SVIDs (SPIFFE Verifiable Identity Documents). SPIRE is the reference implementation.

The SPIFFE Identity Format

Every workload gets a URI SAN of the form:

spiffe://<trust-domain>/<path>

# Examples:
spiffe://prod.example.com/ns/payments/sa/payment-processor
spiffe://prod.example.com/ns/checkout/sa/checkout-svc
spiffe://staging.example.com/k8s/cluster1/ns/default/pod/my-pod

The trust domain is your cluster/org identifier. The path encodes the workload's namespace and ServiceAccount. This identity is cryptographically verifiable — it's in the X.509 cert's SAN field, signed by SPIRE's CA.

SPIRE Architecture

Registering a Workload in SPIRE

# Create a registration entry for a K8s workload
spire-server entry create \
  -spiffeID spiffe://prod.example.com/ns/payments/sa/payment-processor \
  -parentID spiffe://prod.example.com/k8s-node/node1 \
  -selector k8s:ns:payments \
  -selector k8s:sa:payment-processor \
  -ttl 3600

# Workload fetches its SVID via the Unix socket
# (SPIRE agent mounts /run/spire/sockets/agent.sock into pods)
spire-agent api fetch x509 \
  -socketPath /run/spire/sockets/agent.sock

SPIFFE vs Kubernetes ServiceAccount Tokens

🧠 Knowledge Check