Retire Duplicate Service Keys

A shared key makes two unrelated services one security principal. If one workload is compromised, the key may reach everything the other workload can reach. It also becomes hard to tell which service made a provider call. OWASP's secrets and authorization guidance support least privilege and clear ownership, which a common key can undermine.

Begin with a safe identifier for each active key. Map the services, jobs, and people that use it. Compare actual provider usage where available. Do not search for or paste raw key material into an inventory just to identify duplicates; use secret-manager references and provider IDs.

Separation map

The example is a worksheet, not a claim about a real system. For each caller, create a distinct credential if the provider supports it. If the provider offers only one account-wide key, consider an internal broker with per-caller authorization and log the residual provider risk. Do not claim separation when all callers still use the same upstream bearer value.

Phased retirement

Move one caller at a time to its new key. Verify a permitted operation and a forbidden operation for that caller. Watch provider usage until the old key has no expected calls. Then revoke the shared key at the provider and verify rejection. Include scheduled jobs and disaster-recovery deployments, which may use the old value only rarely.

Record which deployments changed, the provider-side key IDs, the observation period, and the rollback path. A rollback must not silently restore a key suspected of exposure. If a caller cannot be moved, keep the shared key on a dated hold with a named owner and a limited compensating control. Before approving the split, confirm that the provider supports separate scopes and independent revocation for the new keys.