gobridge

Runbook: Credential Expiry / Rotation Failure

Applies to: any transport whose credentials resolve from a secret store (SSM on the shipped AWS image; file:// on the reference binary). Audience: on-call operators. Risk: low to act — the resolver serves the last-known-good credential through a transient backend blip; the work is fixing the source.

Symptom

Diagnosis

  1. Separate “rotation not applied” from “new credential rejected”. The metrics under GoBridge/Runtime split cleanly (monitoring.md#key-metrics):
    • CredentialRotationApplied — a rotation reached a live transport (success).
    • CredentialRefreshFailures — a resolve failed during the rotation poll.
    • CredentialResolveFailure (code) — a repository fetch failed, tagged with the error code so a permission denial (NOT_AUTHORIZED) is distinguishable from a backend outage (UNAVAILABLE).
    • CredentialStaleServed (code) — the resolver returned an expired credential after a retryable fetch error; a rising value means the secrets backend has been unreachable longer than the cache TTL.
  2. Classify from the error code (troubleshooting.md):
    • TEMPORARY_AUTH_FAILURE — resolution succeeded but the broker reports “auth not yet propagated”: a just-rotated credential not yet active, or clock skew. Usually clears within seconds (troubleshooting.md#temporary_auth_failure).
    • CredentialResolveFailure{code=NOT_AUTHORIZED} — the bridge’s IAM role lost read access to the secret; {code=UNAVAILABLE} — the backend is down.
  3. On the shipped AWS image, secrets resolve from SSM at startup and admin_api_key_param is mandatory. A rotation that never lands often means the SSM parameter was updated under a different name or the task role cannot read it.

Action