A CI migration standardizes Vault auth and only production jobs fail AppRole login after CIDR restrictions are enabled.
A Vault AppRole rollout works in staging and fails in production
The role is correct, yet login fails because the production runner exits through another NAT identity than the SecretID binding assumed.
Scenario
What to check first
- Identify the primary failure signal in the The SecretID Trusted a Path the Real Runner Never Used scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Validate the real egress identity of the runner path before widening Vault role policy.
Questions worth viewing together
Community-field security problem inspired by HashiCorp Discuss patterns where AppRole SecretID CIDR binding mismatched real production egress. CIDR-bound auth often fails on hidden NAT differences rather than on Vault role misconfiguration.
Teams often blame expired SecretIDs when the source IP simply no longer matches the bound range.
AppRole hardening with CIDR should be paired with explicit runner egress mapping per environment.
Similar cases seen in the field