← Problem Library
Security L7 SECURITY-1386 · 15 min

A Cilium deny policy looks correct and one egress path remains open

The deny rule exists, yet a broader attached allow path still grants egress for a subset of pods selected through the sidecar layer.

SecurityPlatform ReliabilityLevel 7Pro15 min
Scenario

A zero-trust egress tightening is deployed and later one pod group still reaches the internet even though the deny policy appears correct.

What to check first
  • Identify the primary failure signal in the The Deny Matched the Workload and the Sidecar Brought a Broader Exception Along scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Compare effective selectors across sidecar and workload policy attachments before widening the deny.

Questions worth viewing together
What should you verify first when A Cilium deny policy looks correct and one egress path remains open appears?

Community-field security problem inspired by Cilium policy discussions where a broader sidecar selector kept egress open. Policy surprises often come from broader selectors attached through helper layers like sidecars or injected namespaces.

What usually causes A Cilium deny policy looks correct and one egress path remains open in production?

Teams often blame stale policy propagation when another broader allow still selects the same traffic.

What should you document after resolving A Cilium deny policy looks correct and one egress path remains open?

Selector scope should be reviewed holistically across workload, sidecar, and namespace-attached policies.