Network Segmentation Guide
Kubernetes-Netzwerke sind standardmäßig flach — jeder Pod kann jeden anderen erreichen. Vier Schichten: Default-Deny-Baseline, Namespace-Isolation, mTLS und Egress-Control für KI-Agenten.
4 Segmentierungsschichten
Start with deny-all for every namespace. Add explicit allow rules only for required communication paths.
# Step 1: Apply default-deny to every application namespace
# This NetworkPolicy denies ALL ingress and egress by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: moltbot-agents # Apply to each namespace
spec:
podSelector: {} # Matches ALL pods in namespace
policyTypes:
- Ingress
- Egress
# No rules = deny all ingress and egress
---
# Allow DNS egress (required for service discovery)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-dns-egress
namespace: moltbot-agents
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- ports:
- port: 53
protocol: UDP
- port: 53
protocol: TCPPrevent cross-namespace communication unless explicitly required. Separate concerns: AI agents, databases, monitoring, ingress — each in isolated namespaces.
# Allow moltbot-agents to reach llm-gateway in llm-services namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-llm-gateway-egress
namespace: moltbot-agents
spec:
podSelector:
matchLabels:
app: moltbot-agent
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: llm-services
podSelector:
matchLabels:
app: llm-gateway
ports:
- port: 8080
protocol: TCP
# Deny: moltbot-agents → database namespace (agents never touch DB directly)
# Deny: moltbot-agents → monitoring namespace
# Allow: monitoring namespace → moltbot-agents (metrics scraping only)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-prometheus-scrape
namespace: moltbot-agents
spec:
podSelector: {}
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring
ports:
- port: 9090 # metrics port onlyMutual TLS encrypts and authenticates all service-to-service communication. Even if network segmentation is bypassed, mTLS prevents unauthorized service access.
# Istio: enforce STRICT mTLS cluster-wide
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: strict-mtls
namespace: istio-system # Cluster-wide policy
spec:
mtls:
mode: STRICT # Reject any non-mTLS connection
---
# AuthorizationPolicy: allow only specific service-to-service calls
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: moltbot-agent-authz
namespace: moltbot-agents
spec:
selector:
matchLabels:
app: moltbot-agent
action: ALLOW
rules:
- from:
- source:
principals:
- "cluster.local/ns/ingress-nginx/sa/ingress-nginx" # Only ingress can call agents
# All other callers: implicitly denied
---
# Cilium alternative: mTLS via CiliumNetworkPolicy with SPIFFE identity
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: moltbot-mtls-policy
spec:
endpointSelector:
matchLabels:
app: moltbot-agent
ingress:
- fromEntities:
- cluster # Only in-cluster traffic
toPorts:
- ports:
- port: "8080"
rules:
http: [{}] # L7 inspection enabledAI agents must not make arbitrary outbound connections. Strict egress control prevents data exfiltration and C2 communication if an agent is compromised.
# Cilium FQDN-based egress: only allow specific external hosts
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: moltbot-agent-egress
namespace: moltbot-agents
spec:
endpointSelector:
matchLabels:
app: moltbot-agent
egress:
# Allow: LLM gateway (internal)
- toEndpoints:
- matchLabels:
app: llm-gateway
toPorts:
- ports: [{port: "8080", protocol: TCP}]
# Allow: specific external APIs (if using cloud LLM)
- toFQDNs:
- matchName: "api.openai.com"
toPorts:
- ports: [{port: "443", protocol: TCP}]
# Block: everything else including:
# - AWS metadata (169.254.169.254)
# - Internal admin interfaces
# - All other external IPs
egressDeny:
- toCIDRSet:
- cidr: "169.254.169.254/32" # Block cloud metadata API
- cidr: "10.0.0.0/8" # Block internal unless explicitly allowed above
except:
- cidr: "10.0.1.0/24" # Allow: LLM gateway subnetHäufige Fragen
What is the difference between Kubernetes NetworkPolicy and Cilium NetworkPolicy?
Kubernetes NetworkPolicy (standard): L3/L4 only (IP addresses and ports). Requires a CNI plugin that implements it (Calico, Cilium, Weave). No L7 awareness (can't filter by HTTP method or path). No FQDN support (can't allow api.openai.com — only IP ranges). Cilium NetworkPolicy (extended): Adds L7 policy (HTTP methods, paths, gRPC methods, DNS). FQDN-based egress (allow by domain name, Cilium resolves DNS). SPIFFE/SPIRE identity support. Tighter integration with Cilium's eBPF dataplane. In practice: use standard NetworkPolicy for basic isolation (works with any CNI). Add Cilium CiliumNetworkPolicy for L7 filtering and FQDN-based egress when using Cilium CNI.
Does network segmentation break AI agent functionality?
Only if implemented too aggressively without testing. Common breakage points: DNS not allowed — agents can't resolve service names. Solved: always add explicit DNS egress (port 53). LLM gateway blocked — agents can't reach the LLM. Solved: explicit egress rule to LLM gateway namespace/pod selector. Tool APIs blocked — agents with external API tools can't call them. Solved: FQDN-based egress rules for each tool's domain. Metrics blocked — Prometheus can't scrape agent metrics. Solved: ingress rule allowing monitoring namespace. Recommended approach: start with default-deny + DNS allow, then add rules as agents fail. Use 'dry-run' mode in some CNI plugins to preview what would be blocked before enforcing.
How do I segment the network for multi-tenant AI deployments?
Multi-tenant network segmentation for AI: Tenant namespace isolation: each tenant gets their own namespace with default-deny. No cross-tenant traffic allowed (strict namespaceSelector rules). Shared services access: tenants can reach shared LLM gateway, but each tenant's agents are isolated from other tenants' agents. Database isolation: each tenant's vector store in a separate namespace, accessible only from that tenant's agent namespace. Monitoring: centralized monitoring namespace scrapes all tenant namespaces (one-directional). Ingress: single ingress gateway routes to tenant namespaces based on tenant ID in request headers. Cilium SPIFFE identities ensure that even if a tenant's pod gets a different IP (e.g., after restart), the identity-based policy still applies correctly.
Should I use Istio service mesh or just NetworkPolicies?
Both serve different purposes and are complementary: NetworkPolicy (L3/L4): controls which pods can communicate at the network level. Low overhead. Works with any CNI. Mandatory baseline for any production cluster. Istio service mesh (L7 + mTLS): mutual TLS authentication between all services. L7 AuthorizationPolicy (RBAC for service-to-service calls). Traffic management (circuit breaking, retries, canary). Observability (traces, metrics per service pair). Higher complexity and resource overhead (~50-100MB per sidecar). Recommendation: always use NetworkPolicy as the baseline. Add Istio for high-security environments (financial, healthcare) where service-to-service authentication and L7 RBAC are required. For AI workloads: mTLS ensures that a compromised agent can't impersonate the LLM gateway.
Weiterführende Ressourcen
Network Segmentation Security Score Calculator — Wie sicher ist dein Netzwerk?
Beantworte 5 Fragen und erhalte deinen Network Segmentation Security Score (0-100). Dieser Score basiert auf Best Practices aus der Produktion.
Daypass — 24h Full Access für €3
Einmalig pro User/Kreditkarte. Volle 24 Stunden Zugang zu allen Security-Tools.