← Problem Library
Security L7 SECURITY-1336 · 15 min

A Cilium network policy blocks unexpected egress only in one security...

Policy looks right, yet the egress decision is made on stale name-to-identity context for one namespace after relabeling.

SecurityPlatform ReliabilityLevel 7Pro15 min
Scenario

A security namespace is relabeled and later FQDN-based egress policy behaves inconsistently for only some pods.

What to check first
  • Identify the primary failure signal in the The FQDN Policy Evaluated Yesterday's Identity 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

Inspect DNS proxy and endpoint identity cache state before broadening the egress policy.

Questions worth viewing together
What should you verify first when A Cilium network policy blocks unexpected egress only in one security... appears?

Community-field security problem inspired by Cilium community cases where DNS-proxy-backed policy decisions used stale endpoint identity after relabeling. Name-based policy decisions can stale independently from pod labels and policy objects.

What usually causes A Cilium network policy blocks unexpected egress only in one security... in production?

Teams often blame DNS when the decision cache still maps the name to an old endpoint identity.

What should you document after resolving A Cilium network policy blocks unexpected egress only in one security...?

Identity-aware network policy engines need convergence checks after relabeling workloads that use FQDN rules.