← Problem Library
Security L7 SECURITY-1347 · 15 min

A Cilium policy allows one FQDN and still breaks egress because the app resolves through a sidecar stub that rewrites DNS search paths before the FQDN cache records the final name

The rule looks correct, yet the cached name identity differs from the actual final lookup because the sidecar mutates the query path.

SecurityPlatform ReliabilityLevel 7Pro15 min
Scenario

A secure namespace uses a service mesh sidecar and later one external dependency fails only under FQDN-based egress controls.

What to check first
  • Identify the primary failure signal in the The Policy Whitelisted the Name Users See and the Sidecar Asked for Another One First 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

Observe the real DNS query path emitted by the workload stack before broadening the allow list.

Questions worth viewing together
What should you verify first when A Cilium policy allows one FQDN and still breaks egress appears?

Community-field security problem inspired by Cilium community cases where a sidecar DNS rewrite caused FQDN policy mismatches. FQDN policy correctness depends on the actual queries emitted on the wire, not only on the hostname in application config.

What usually causes A Cilium policy allows one FQDN and still breaks egress in production?

Teams often blame stale DNS cache when a sidecar changed the queried name before policy evaluation.

What should you document after resolving A Cilium policy allows one FQDN and still breaks egress?

FQDN-based policy should be validated against service-mesh or sidecar DNS rewrites, not just the app config hostname.