A self-hosted CI server's OIDC subject is the job's folder path, and CI admins can rename folders. What do you require before federating production?
answer
- who mints the claim you are trusting
- a path can be renamed
- names get recycled after deletion
- CI admin becomes cloud IAM admin
- stable identifier or do not federate production
basics
~20 sRequire a stable, non-reusable identifier in the subject, a tenant-specific audience, one role per environment, and change control over the issuer itself - because whoever administers that CI server now effectively administers the cloud roles it can assume.
solid answer
~50 sFederating into a self-hosted issuer means the cloud has outsourced part of its authorization to that server's operators. If the subject is a mutable path, the identity is not an identity: renaming a folder re-points an existing trust, and creating a new job in a trusted folder silently satisfies it, and no cloud configuration changes to show it. The organisational answer matters more than the technical one. Require that the issuer mint an identifier that is stable and never recycled, and condition on that rather than on a path. Require an audience unique to your tenant. Give each environment its own role with minimal permissions. Then decide, explicitly, that operating that CI server is a privileged role with the same change control and separation of duties as editing cloud permissions - and if that cannot be guaranteed, do not federate production into it at all.
go deeper
Take away the core idea: the cloud trusts whatever the identity provider says, so a subject that can be renamed is not a reliable name for a workload. You are not expected to design the controls at this level.
Be able to walk the two failure paths - a rename re-pointing an existing trust, and a recreated job inheriting a deleted one's access - and say why neither leaves a trace in cloud configuration.
Demonstrate the controls: bind to a stable non-recycled identifier, use a tenant-specific audience, split roles per environment, and alert on unseen subjects assuming a known role.
Own the delegation question. Say plainly that federating makes CI administration a cloud privilege, negotiate separation of duties and generated trust conditions, and be willing to keep production out of an issuer whose subjects cannot be trusted.
## The claim is only as good as the issuer Every federated trust decision rests on a claim minted by somebody else. With a managed CI platform you are relying on that vendor to mint subjects that mean what they appear to mean. With a self-hosted CI server, the vendor is *you* - specifically, whoever administers that server. That is a governance fact before it is a technical one, and it is the thing to say first in an interview. ## Why a path is not an identity Suppose the subject claim encodes the job's location in the server's hierarchy - a folder path plus a job name. It reads precisely. It matches exactly. It is still not an identity, for two reasons: - **It is mutable.** Renaming a folder changes what the issuer mints for the jobs inside it, and renaming a *different* folder to the trusted name re-points the trust onto entirely different jobs. Nothing in the cloud changed; nobody edited a policy; the assumption path moved. - **It is reusable.** Delete a job and create a new one with the same name in the same folder and the new one inherits the old one's cloud access. Names are recycled constantly - a rebuild, a migration, a team reorganising its folders. Both failures share a shape: the trust condition is satisfied by a *string*, and the string is controlled by whoever can arrange the hierarchy. The person best placed to exploit that is a malicious or careless insider with CI administration rights - not an outsider - and the assets at risk are the cloud role's reach plus something subtler: the audit truth of who deployed. When the subject is a recycled path, the cloud's record of "this identity assumed the role" no longer resolves to a job, a team, or a person. ## What to require **Technical requirements, stated as conditions of federating at all:** 1. **A stable, non-recycled identifier in the subject.** If the issuer can mint a durable identifier for a pipeline definition - one that does not change on rename and is never reissued after deletion - condition on that. Where the only stable anchor is the source of the pipeline definition itself, bind to that instead of to the runtime location. 2. **An audience unique to your tenant**, so a token minted for another consumer of the same CI server is inert against your cloud. 3. **One role per environment, least privilege on each**, so a re-point that does happen lands somewhere survivable rather than in production. 4. **Short credential lifetimes and no fallback to a stored key** - a long-lived key kept "in case federation breaks" quietly reinstates the risk federation was bought to remove. **Organisational requirements, which are the real answer:** 1. **Treat issuer operation as a privileged role.** Administering the CI server is, functionally, the power to mint assertions your cloud believes. It deserves the same access review, approval flow and audit that editing cloud permissions gets. Very often the two groups are different people with very different expectations of each other, and nobody has written that down. 2. **Separation of duties.** The people who can rename folders or create jobs should not be the same people who define which subjects a production role trusts, and neither group should be able to complete an escalation alone. 3. **Alert on the joins.** Two events deserve notification: a change to a federated role's trust conditions, and a role assumption arriving under a subject that has not been seen before. The second catches the rename case that no policy edit would reveal. 4. **A documented decision about production.** If the issuer cannot offer a stable subject, or its administration cannot be brought under equivalent control, the honest outcome is that production does not federate into it. Non-production can; production goes behind a separate issuer, a deployment path with human approval, or a broker you do control. ## The tradeoff to own The pressure runs the other way. Self-hosted CI usually exists because of cost, data residency, or hardware the managed platforms cannot offer, and the team running it values autonomy. Telling them that folder renames now require a change ticket is a real imposition, and refusing to federate production means somebody keeps using a long-lived key - which is worse. So the principal-level call is not "forbid it": it is to trade the constraint for something. Offer generated trust conditions so the CI team never edits cloud policy by hand, take the rename burden off them by binding to an identifier they do not have to think about, and accept a slower path only for the production environment. What you must not do is accept a mutable path as an identity and record it as compliant, because that leaves the cloud trusting a string that anyone with CI admin can rewrite - and leaves the audit trail claiming otherwise.
- What would you monitor to catch a trust that has silently re-pointed?Alert on two things: any edit to a federated role's trust conditions, and any role assumption whose subject value has not been seen before for that role. The second is the one that matters here, because a rename produces no configuration change anywhere - the only observable is a familiar role suddenly being assumed under a new or newly-meaningful subject.
- The CI team argues this is bureaucracy for a risk that has never materialised. How do you answer?Agree on the goal and move the cost. The requirement is that production access cannot be granted by a rename; it is not that renames need tickets. Generate trust conditions from the pipeline definition so they never touch cloud policy, bind to an identifier they do not manage, and reserve the slow path for production only. If none of that is possible, the honest trade is that production stays behind an approval boundary.
- Does keeping a long-lived cloud key as a fallback for when federation breaks change the analysis?Yes, and it undoes it. A stored key is assumable by anything that can read it, it does not expire, and it will not be rotated on the day the fallback is used. The estate's security then equals the weaker of the two paths. If a fallback is genuinely needed, it should be a second federated identity or a break-glass credential behind approval and alerting, not a key in a secret store.
saying these in an interview costs you the question
- Trusts a mutable path as a durable workload identity
- Ignores that CI administrators can re-point the trust
- Assumes the cloud audit trail reveals a folder rename
- Keeps a long-lived key as a federation fallback
- Treats self-hosted and managed issuers as equally trustworthy