← Problem Library
Security L6 SECURITY-1373 · 12 min

An Elastic logging sidecar reconnects (elastic-sidecar-mounted-new-secret-but-kept-old-key-in-env-file)

The secret changed on disk, yet the running process still uses the boot-time materialized credential.

SecurityPlatform ReliabilityLevel 6Pro12 min
Scenario

An API key rotation completes and later only one logging sidecar continues failing authentication despite the new secret being mounted.

What to check first
  • Identify the primary failure signal in the The Secret Rotated Under the Pod and the Process Never Let Go of the Old Key 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

Distinguish file refresh from process credential reload before regenerating keys again.

Questions worth viewing together
What should you verify first when An Elastic logging sidecar reconnects (elastic-sidecar-mounted-new-secret-but... appears?

Community-field security problem inspired by Elastic and Kubernetes community threads where a rotated API key stayed stale inside a running sidecar. Projected secret updates do not guarantee the process reloads credentials it copied into env or temp files at start.

What usually causes An Elastic logging sidecar reconnects (elastic-sidecar-mounted-new-secret-but... in production?

Teams often blame Kubernetes secret propagation when the process never re-read the new key from disk.

What should you document after resolving An Elastic logging sidecar reconnects (elastic-sidecar-mounted-new-secret-but...?

Rotation runbooks should verify application reload mechanics, not just secret object updates.