Machine Identity: Secretless Pipelines

The half of “modern auth” everyone forgets

Say “modern auth” and everyone pictures the human half: single sign-on, MFA, conditional access. Meridian’s rebuild has all of that via Entra ID (Lesson 4.1). But walk the estate and count identities: a few hundred humans — and thousands of machine principals. Pipelines deploying infrastructure, apps reaching databases, jobs reading storage. The realistic 2026 pattern, observed across many estates: the workloads got modern identity (Lesson 2.3 wired managed identity and Key Vault references correctly), while the pipelines that deploy everything still authenticate with a service-principal client secret pasted into a CI variable two years ago.

That inversion — platform ready, pipelines lagging — makes CI the softest target in an otherwise-hardened estate. A stored secret is a bearer credential: anyone who exfiltrates the CI variable is the deployment principal, from anywhere, until someone notices. And these secrets expire, so someone rotates them by hand, badly, forever.

The fix: nothing stored, everything federated

Workload identity federation removes the stored secret entirely. The CI platform issues the pipeline run a short-lived, signed OIDC token asserting what it is (“repo X, branch main, environment prod”). The cloud’s identity provider is configured to trust that issuer for one specific subject — and exchanges the token for cloud credentials on the spot:

Stored-secret world:
  pipeline has $AZURE_CLIENT_SECRET  ->  anyone with the value is you, 24/7,
                                         from anywhere, until rotation

Federated world:
  pipeline run proves "I am repo X / branch main / env prod" via OIDC
  ->  identity provider checks the claim against the federated credential
  ->  issues short-lived tokens, only for that subject, only during a run
  Nothing to steal at rest. Nothing to rotate. Branch and repo are part
  of the identity - a fork or feature branch simply is not the principal.

Prompt first: the migration

Audit this CI/CD estate for stored cloud credentials and produce a
federation migration plan:
1. INVENTORY: every service connection / CI variable holding a client
   secret, key, or connection string; which pipelines use each; when last
   rotated
2. FEDERATE: for each, the workload-identity replacement - subject claims
   (repo, branch, environment), the federated credential config, and the
   role assignment it should carry (least privilege, scoped to what that
   pipeline deploys)
3. REVOKE: the removal order - secrets deleted from the identity provider,
   not just from CI variables
4. GUARD: a scheduled check that fails when any new stored cloud secret
   appears in CI configuration
Order the plan lowest-risk-first and flag any pipeline whose platform
cannot do OIDC federation - those need a dated exception in the decisions
register, not silence.

Step 3 is where migrations quietly fail: deleting the CI variable while the secret remains valid on the service principal leaves the credential alive in whoever’s clipboard it ever passed through. Revocation happens at the identity provider. And step 4 makes the posture self-maintaining — the guard is a pipeline citizen like Lesson 6.3’s drift checks, not a one-time cleanup.

The same rule, all the way down

Federation is one instance of the rule this training has been building since Lesson 2.3: identity is asserted and verified, never stored and presented.

When every row is identity-based, Lesson 4.1’s “configuration contains references, never values” stops being an app-hardening rule and becomes the estate’s physics: there is simply nothing lying around to steal.

Key takeaway

Machine identities outnumber humans, and the pipeline tier is where modern auth lags last. Federate CI identity so nothing is stored, revoke at the identity provider, guard against regression on a schedule, and extend the assert-don’t-store rule to every row of the connection table. Eliminate where you can, vault only what must exist.