← Problem Library
Security L7 SECURITY-1343 · 15 min

An Elastic ingest pipeline keeps 401ing (elastic-sidecar-kept-using-projected-old-api-key-volume)

The new key exists, yet one workload keeps failing because its projected secret volume belongs to a pod template that never rolled.

SecurityIAMPlatform ReliabilityLevel 7Pro15 min
Scenario

A credential rotation completes and one log shipping path still fails with unauthorized errors even though the cluster secret was updated everywhere.

What to check first
  • Identify the primary failure signal in the IAM 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

Confirm pod-template rollout and secret volume refresh before minting another key.

Questions worth viewing together
What should you verify first when An Elastic ingest pipeline keeps 401ing (elastic-sidecar-kept-using-projected... appears?

Community-field security problem inspired by Elastic community patterns where a sidecar kept using an old projected API key after rotation. Cluster secret updates do not automatically mean every pod reopened the new secret material.

What usually causes An Elastic ingest pipeline keeps 401ing (elastic-sidecar-kept-using-projected... in production?

Teams often blame API key scope when the stale consumer never rolled onto the new projection.

What should you document after resolving An Elastic ingest pipeline keeps 401ing (elastic-sidecar-kept-using-projected...?

Credential rotations should be tied to rollout verification, not just secret update completion.