← Problem Library
Security L6 SECURITY-1396 · 14 min

A Cilium egress deny policy appears tight and one init container still...

The policy is correct for steady-state pods, yet the short init lifecycle finishes before the enforcement point catches up.

SecurityPlatform ReliabilityLevel 6Pro14 min
Scenario

An egress lockdown looks complete and later a bootstrap path still manages to fetch external content during pod start.

What to check first
  • Identify the primary failure signal in the The Deny Was Real and the Init Container Lived Too Briefly to Meet It 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

Measure enforcement timing for init lifecycle paths before adding broad deny exceptions or disabling the init container.

Questions worth viewing together
What should you verify first when A Cilium egress deny policy appears tight and one init container still... appears?

Community-field security problem inspired by Cilium policy discussions where an init container outran egress deny enforcement. Short-lived container phases can expose timing windows that steady-state policy checks never reveal.

What usually causes A Cilium egress deny policy appears tight and one init container still... in production?

Teams often blame stale policy application broadly when the real issue is a lifecycle race on an init path.

What should you document after resolving A Cilium egress deny policy appears tight and one init container still...?

Security validation should include init containers and bootstrap phases, not only long-running app containers.