Your estate has long-lived cloud keys stored in dozens of pipelines. How would you plan the move to OIDC federation, and which credentials cannot move?
answer
- inventory from the provider, not the store
- rank by blast radius, delete the unused
- role per pipeline, condition per environment
- prove it is dead before deleting
- the tail gets scope and lifetime instead
basics
~20 sInventory every stored credential, rank by blast radius, and migrate the highest-privilege deploy keys first. Run federation alongside the old key, cut over, then confirm from provider usage data before deleting. Anything without a federation path gets shortened lifetime and tighter scope instead.
solid answer
~50 sTreat it as a decommissioning programme, not a config change. First build the inventory — secret stores are only one location; keys also sit on persistent runners, in base images, and in machine accounts nobody owns. Then rank by blast radius rather than by ease: production deploy roles first, read-only reporting tokens last. Migrate one pipeline at a time, creating a role per pipeline with a subject condition pinned to a protected branch or environment, and grant only the permissions that pipeline actually uses. Keep the old key live briefly, cut the pipeline over, then use the provider's last-used telemetry to prove nothing still calls it before you delete it — deleting on the assumption it is unused is how you cause the outage that discredits the programme. Some credentials will not move: third parties with no federation support, CI whose issuer the provider cannot reach, and break-glass accounts. For those, shorten lifetimes, narrow scope, isolate them in one place, and alert on use.
go deeper
Know the direction of travel: stored cloud keys are replaced by short-lived credentials obtained per run, and any key nobody uses should be deleted outright.
Describe the per-pipeline mechanics — a dedicated role, a pinned subject condition, permissions matching actual use — and the run-both-then-cut-over sequence.
Show how you retire safely: provider-side inventory, last-used telemetry before deletion, allowance for infrequent scheduled jobs, and alerting if a retired key is used again.
Own it as a programme with an ordering principle, an honest account of the credentials that cannot migrate, and the preventive controls that stop the inventory refilling once attention moves elsewhere.
## Framing "Move to OIDC" sounds like a configuration task and behaves like a decommissioning programme. The technical step per pipeline is genuinely small. The hard parts are finding every credential, deciding the order, proving a key is dead before deleting it, and handling the tail that cannot migrate. Interviewers ask this because it separates people who have configured federation once from people who have run the change across an organisation. ## Step 1 — Inventory, and look beyond the secret store The CI secret store is the obvious location and the incomplete one. Long-lived credentials also live: - on persistent self-hosted runners, in home-directory config files left by an interactive login, - baked into base images and build tooling, - in machine accounts created for a migration years ago and never retired, - in local developer environments that mirror the pipeline's setup. The more reliable inventory is built from the **provider side**: enumerate every credential the cloud account has issued and when each was last used. That finds keys nobody remembers, which is exactly the population you most want gone. ## Step 2 — Rank by blast radius Order by what the credential can do, not by which pipeline is easiest to change. Roughly: 1. Production deploy and infrastructure-mutating credentials. 2. Credentials that can publish artifacts consumers install — a compromised publish key poisons downstream users. 3. Non-production write credentials, which are often over-permissioned and reachable from pipelines with weaker review. 4. Read-only reporting tokens. Unused long-lived keys should simply be deleted rather than migrated. That is the cheapest risk reduction in the programme and should happen first. ## Step 3 — Migrate with the trust condition as the design artifact Per pipeline: - Create a **role per pipeline**, not a shared deploy role. Shared roles force broad trust conditions and union permissions, and they destroy the audit signal. - Write the **subject condition** to match only runs you would approve — a protected environment where the platform supports it, otherwise an exact branch ref. Prefer exact matching over wildcards. - Pin the **audience** to a value specific to this relying party. - Grant the **permissions the pipeline actually uses**, which you can derive from the old key's access history rather than guessing. - Verify negatively: try the exchange from a scratch branch and confirm it is refused. ## Step 4 — Cut over and prove the key is dead Run both paths briefly, switch the pipeline to federation, then wait and watch the old credential's last-used timestamp in the provider's audit data. Only delete when telemetry shows no use across a full cycle — including monthly or quarterly jobs, which are the classic thing a two-week cutover window misses. One self-inflicted outage from a hasty deletion will stall the whole programme. Also instrument the other direction: alert if a supposedly retired key is used after cut-over. That is either a forgotten consumer or an attacker. ## Step 5 — The tail that cannot move Be honest about this in an interview; a plan that claims zero long-lived credentials is not credible. - **Third parties with no federation support.** Many SaaS APIs accept only an API key. Some package registries now support publishing via OIDC-based trusted publishing, and where that exists it is worth adopting; where it does not, the key stays. - **CI the provider cannot reach.** Federation requires the relying party to fetch the issuer's public keys. A self-hosted CI system with no publicly reachable discovery endpoint cannot federate to a public cloud without exposing one or arranging a private path. - **Non-pipeline machine identities.** Credentials used by long-running services outside CI are a different problem, better solved by the platform's own workload identity than by CI federation. - **Break-glass credentials**, deliberately kept for the case where the identity path itself is broken. For everything in the tail: minimum scope, shortest lifetime the provider supports, one custodian, storage in a dedicated secret manager rather than scattered CI variables, scheduled rotation, and alerting on use from unexpected sources. ## Step 6 — Prevent regression Without a stop on new keys, the inventory refills. Practical controls: a policy that denies creation of long-lived keys in accounts that have a federation path, a scanner over CI configuration for credential-shaped variables, and a review requirement on trust-policy changes so a permissive subject condition cannot be merged quietly. ## What success looks like Not "zero secrets", but: every long-lived credential has a named owner, a justification, a scope, and an expiry; the highest-privilege ones are gone; and the remaining ones are few enough that a human can review the list.
- Why build the credential inventory from the cloud provider rather than from CI configuration?Because CI configuration only shows credentials someone deliberately registered. The provider knows every credential it issued and when each was last used, which surfaces keys on runners, in images, and in forgotten machine accounts. It also gives you the last-used data you need to retire a key safely and the access history to size the replacement role's permissions.
- How do you decide the permissions for the replacement federated role?From the old credential's access history rather than from the documentation or a guess. Providers record which API calls a credential made; that set is the starting grant. Then run the pipeline against it in non-production and fix denials before cut-over. Copying the old key's policy just preserves whatever over-permissioning already existed.
- What stops the estate refilling with long-lived keys after the migration?A preventive control plus a detective one. Preventively, deny creation of long-lived credentials in accounts that have a federation path available. Detectively, scan CI configuration for credential-shaped variables and alert on newly issued keys. Without both, the inventory regrows, because creating a key is still the fastest way to unblock a build.
saying these in an interview costs you the question
- Deletes old keys on assumption rather than usage data.
- Migrates every pipeline onto one shared federated role.
- Claims federation removes all long-lived credentials.
- Orders the work by ease instead of blast radius.
- Copies the old key's permissions onto the new role unchanged.