Credentials and Permission Boundaries in Pipelines

Why this matters

A pipeline uses one cloud key with full access for every job, prints it in a debug log during an incident, and the key lives in log storage for a year. Or a pull request from a fork runs with write tokens and exfiltrates secrets through a test script. The pipeline is the highest-value target in the build system because it concentrates trust; its permissions deserve the same design as production access, from M08's least-privilege lesson applied early.

Concepts

Scope tokens per job, not per pipeline. The deploy job needs write to production; the lint job needs read on the repo and nothing else. Platforms expose this as job-level permissions; the default is usually wider than any single job needs, so narrowing is explicit work. Review the permission block with the same suspicion as a firewall rule: every granted scope is a path a malicious or mistaken step can walk.

Prefer short-lived identity over stored secrets. Workload identity (OIDC federation to the cloud, ephemeral registry tokens minted per run) removes the whole class of leaked-static-credential incidents: there is no key to rotate because no key persists. Where stored secrets remain, they live in the platform's secret store, referenced by name, masked in logs, rotated on a schedule, and never in the repo, where M04 lesson 4 already showed they cannot be deleted, only rotated after exposure.

Logs and caches are secret sinks. Masking rules catch the known patterns and miss the novel one, so the stronger discipline is to never print credentials (enable debug logging per run, never by default) and to exclude secret material from cache keys and cached paths. A cache key containing a token stores the token in the cache backend under a guessable name; a wrong cache key restoring another branch's files is the same shape of hole without any secret at all, and lab L18 makes both concrete.

Fork and dependency boundaries complete the picture. Jobs triggered by untrusted code run with read-only tokens and no secret access; privileged steps run only on trusted events after review. Third-party actions and pipeline plugins are pinned to digests like any dependency, because a floating action reference is someone else's deploy key into your pipeline.

Worked example

A cache speeds builds but restores the wrong branch's dependencies, and a release ships with last week's library. The key:

key: deps-{{ .Branch }}-{{ hashFiles('package-lock.json') }}

Expected reading: the branch prefix partitions correctly, but a second fault hides beside it: the deploy job reuses the pipeline-wide token with production write for a status update. The repair keeps the key (it is correct) while scoping the deploy job's token to the status API and minting a separate short-lived identity for the actual publish. Verify by listing each job's granted scopes against the minimum its steps need, and by showing a cache restore from the wrong branch failing closed instead of silently mixing. Lab L18 requires both halves: the over-wide token narrowed and the cache key made honest.

The common wrong move

One admin token in the pipeline settings, shared by all jobs and rotated never, because scoping feels like bureaucracy. It converts every step, including third-party actions and fork builds, into a production administrator. The breach report then reads like a mystery that was actually a permission block nobody reviewed. Scope is a design artifact: write it, review it, test the denial.

Lab and next step

Lab L18 narrows an over-privileged pipeline and repairs a dishonest cache key, with denial and restore proof. From here the path continues to M07: operating what the pipeline ships, logs, indicators, backups and runbooks.