Sidecar policies are sensitive to mesh configuration — automatic mTLS, ambient mode, and custom
EnvoyFilter resources can shift the observed traffic pattern. Re-run generation after mesh upgrades.Workload
Theistio-proxy container injected by Istio (mesh version 1.22.x) into an application pod in the app namespace. The sidecar terminates inbound mTLS on port 15006, originates mTLS to peer sidecars, exposes Envoy admin/metrics on 15090/15021/15020, and maintains an xDS gRPC stream to istiod in istio-system on port 15012.
Generated NetworkPolicy
Generated CiliumNetworkPolicy
Generated seccomp profile (excerpt)
Full profile contains 148 syscall names. Representative excerpt:What kguardian observed
The sidecar’s traffic shape is dominated by mesh control-plane and peer mTLS rather than application traffic — application-layer requests are tunneled inside the mTLS streams that kguardian sees on port 15006, so the policy stays at L4. Selecting mesh peers by the singlesecurity.istio.io/tlsMode: istio label, as shown above, is a hand-idealization — real generator output emits one rule per observed peer, selecting that peer’s full label set together with a namespace selector. The xDS connection to istiod is long-lived and easy to capture (TCP/15012 to the app: istiod pod in istio-system). Prometheus scrapes for Envoy and pilot-agent metrics show up on 15090 and 15020. Envoy’s syscall set is heavier than a typical Go binary because of io_uring, socketpair, and eventfd2. Caveat: if your mesh uses ambient mode or a non-default sidecar injector, the observed ports and labels will differ — re-generate per environment.