Every open source project's CI pipeline is a quiet confession of how much trust it extends to its own contributors. (Most maintainers would rather you not read theirs.) This week the Cilium team did the opposite. The third and final post in their CI/CD hardening series, published on the CNCF blog, walks through how they manage credentials and verify the artifacts they ship, and lists the parts they have not yet fixed.
What's actually in part three
Credentials are the section most security posts skim past. Cilium walks through theirs in detail. The default GITHUB_TOKEN is held to read-only on contents and packages, and any workflow that needs more has to ask for it by name. Every actions/checkout call sets persist-credentials: false, so a downstream step cannot quietly reuse the checkout token to do something else.
CI and production pushes go to different registries. Everything CI builds lands in a development registry. Anything that becomes a public release tag is pushed by workflows running in distinct GitHub protected environments (release, release-tool, release-helm), each gated behind explicit maintainer approval.
Then the verification half. Container images for cilium, the operator, hubble-relay, and clustermesh-apiserver are signed with Sigstore Cosign in keyless OIDC mode, through a reusable composite action committed inside the repo. SBOMs are generated and attested with the spdxjson predicate. Helm chart OCI artifacts get the same signing treatment. Tag immutability is enabled at the repository level, so a release tag cannot be silently rewritten later. A bot enforces DCO sign-off on every commit and blocks merges when a label says the change is not ready.
