B/MBertrand MbanwiENGINEER / BUILDER All workLet’s talk
KUBERNETES / SOFTWARE SUPPLY CHAINCASE STUDY / 5 minute read

GitOps Supply Chain

A SIGNATURE.A POLICY.A BOUNDARY.

A Kubernetes delivery project that connects a specific build identity to an admission policy, then makes the workload and its operating constraints reviewable in Git.

Independent project · Source-guided policy demonstrationThe 60-second overview
Checked against GitHub
Last successful check · 2026-09-05 22:54 UTC6b7e85bRefresh Career Atlas after public repository changes
THE SHORT VERSION

WHAT THIS
DEMONSTRATES.

  1. 01

    GitHub Actions builds a Go service and signs its image digest using Cosign keyless signing.

  2. 02

    Kyverno verifies the configured workflow identity and issuer for the demo image family, with digest mutation enabled.

  3. 03

    Argo CD reconciles applications, policies, and a secret demonstration into the companion ephemeral platform.

01 / CONTEXT

THE PROBLEM.

A successful image build does not establish who produced a workload or whether it meets a cluster’s baseline. Delivery needs explicit ownership across the build, registry, GitOps controller, and admission boundary.

Constraints that shaped the work

  • Keep cloud provisioning in the companion infrastructure repository.
  • Tie trust to a specific workflow identity on main.
  • Include an unsigned image for a negative verification path.
  • Keep the application small enough that the delivery design remains the focus.
02 / FOLLOW THE SYSTEM

ARCHITECTURE.

Choose a stage to explore its purpose and supporting source.

ARCHITECTURE WALKTHROUGH01 / 04

Build and sign

The workflow builds and pushes an image, then signs its digest using an OIDC-backed Cosign identity. It also builds a deliberately unsigned image with a different digest.

WHAT TO INSPECT

Provenance and SBOM generation are explicitly disabled in this workflow. Signing is implemented; attestations are not claimed.

Read the implementation
EXPLORE THE TRUST BOUNDARY

WHAT SHOULD GET THROUGH?

5 SEP 2026
POLICY ILLUSTRATION

Follow the policy’s intended decision for three different image scenarios.

INPUT / SCENARIO
Demo image + signature from the configured main-branch build workflow
POLICY INTENT
Policy intent: verify signature and bind the admitted image to its digest.

Source-guided illustration. This is not a recorded admission result or cryptographic verification.

03 / ENGINEERING JUDGMENT

THE TRADEOFFS.

01

Trust a workflow identity

Verify a specific keyless signer and issuer instead of distributing a long-lived signing key.

The tradeoffVerification depends on the identity and transparency services. The policy’s image scope must be understood and maintained.

Inspect the decision
02

Keep an explicit negative path

Build an unsigned variant with a distinct digest for rejection checks.

The tradeoffIt creates an intentionally untrusted artifact that must remain clearly separated from the signed deployment.

Inspect the decision
03

Make workload limits visible

Declare the runtime security context, resources, and probes alongside the deployment.

The tradeoffThese controls constrain execution but do not replace application testing or establish runtime security by themselves.

Inspect the decision
04 / WHAT THE WORK SHOWS

OUTCOMES & LIMITS.

Signing and verification are implemented

The reviewed revision contains both the signing workflow and enforcing verification policy. The older README roadmap understates this implementation.

Supporting source

The trust boundary is inspectable

Recruiters can follow the configured workflow subject, issuer, image scope, and digest checks directly in the policy.

Supporting source
THE LESSON

Supply-chain security is a chain of specific claims. A signature authenticates an artifact’s source under a trust policy; it does not prove the software is safe. The useful work is in connecting that identity to an explicit admission boundary.

Where the evidence ends

  • The interactive example explains policy intent; no cluster admission or image signing was executed during this website review.
  • The build disables provenance and SBOM attestations. No SLSA level or compliance certification is claimed.
  • Current GitHub workflow outcomes and companion platform verification should be inspected separately.
05 / CHECK THE WORK

THE SOURCEBOOK.

Reviewed 5 September 2026. These links point to the source revision used for this case study.

Source revision fb4e387 · View current workflow history ↗

KEEP EXPLORING

CodeGuard