Cilium L7 Network Segmentation Policy 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.