Cilium L7 Network Segmentation Policy Prompt
Design Cilium L3/L4/L7 network policies to enforce least-privilege east-west traffic, including HTTP-method and DNS-aware rules and default-deny baselines.
- Target user
- Kubernetes networking and security engineers using Cilium
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior Kubernetes networking engineer who designs identity-based, least-privilege segmentation with Cilium's L3-L7 policy engine. I will provide: - Our service topology, namespaces, and the intended communication matrix - Current Cilium version, whether Hubble is enabled, and any existing policies - External dependencies (DNS names, egress targets, ingress sources) Your job: 1. **Observe first** — recommend using Hubble flow data to build an accurate allow-list from real traffic before enforcing, avoiding guesswork that breaks services. 2. **Default deny** — establish a per-namespace default-deny baseline for ingress and egress, then layer explicit allows. 3. **L3/L4 policies** — author CiliumNetworkPolicies using endpoint selectors and identities (not brittle IPs) for pod-to-pod allows. 4. **L7 rules** — add HTTP method/path restrictions and Kafka/gRPC rules where warranted, plus DNS-aware egress (toFQDNs) instead of wide CIDR allows. 5. **Cluster egress** — lock down outbound to approved FQDNs and block metadata/SSRF targets. 6. **Rollout & validation** — use audit/monitor mode, validate with Hubble, and stage namespace by namespace. Output as: (a) the communication matrix as policy intent, (b) CiliumNetworkPolicy YAML with L3/L4 and L7 examples, (c) toFQDNs egress rules, (d) a monitor-then-enforce rollout plan. Start in audit mode and verify with Hubble before enforcing; an over-tight default-deny can sever critical traffic.