Art of Exploitation

This post is part of a series. If you are new to the underlying technology, start with What is Tekton — The Kubernetes-Native CI/CD Engine and Running OpenShift 4 Locally with CRC before continuing. Everything in this guide runs on the same local CRC setup described there.

If you have ever tried to wire together a production-grade CI/CD platform from scratch on Kubernetes — signing, scanning, testing, releasing, and gating on policy — you know how many moving parts it takes. Konflux solves exactly that. It is the Red Hat-backed cloud-native CI/CD platform that ships all of it, pre-integrated, on top of Tekton Pipelines and OpenShift.

I spent considerable time installing Konflux on a local CRC cluster, working through every step from onboarding a component to triggering a fully gated, Enterprise-Contract-validated release. This post documents everything I learned, and backs it up with a complete set of production-ready YAML blueprints, interactive shell scripts, and a step-by-step learning guide.

• 📖 Full interactive guide: ay-garg.github.io/konflux-pipeline-blueprints
• 💾 GitHub repository: github.com/ay-garg/konflux-pipeline-blueprints
• Hands-On Video Series (YouTube Playlist): https://www.youtube.com/playlist?list=PLdg3gLAAhk5E

What Is Konflux?

Konflux (formerly Red Hat App Studio) is an opinionated, enterprise-grade CI/CD platform built on top of Tekton Pipelines. Where plain Tekton gives you primitives — Tasks, Pipelines, PipelineRuns — Konflux gives you a complete, pre-integrated system with a supply-chain security stack baked in from day one.

It is implemented as a collection of Kubernetes controllers that communicate via Custom Resource Definitions:

• Build Service — watches Component CRs, triggers Tekton PipelineRuns via Pipelines-as-Code on every push or pull request
• Integration Service — watches Snapshot CRs, runs integration test pipelines against every successfully built image
• Release Service — watches Release CRs, executes release pipelines that validate with Enterprise Contract and promote images to registries
• Tekton Chains — automatically signs every built image with cosign after a PipelineRun completes and generates SLSA provenance attestations

The result is a build-test-release workflow where every artifact is signed, attested, scanned, and policy-gated before it reaches production — without you having to wire any of that together manually.

Why Konflux Instead of Plain Tekton?

As covered in my Tekton post, Tekton is the Kubernetes-native CI/CD engine — flexible, powerful, and unopinionated. That last word is both its strength and its challenge. Tekton gives you everything you need to build a pipeline; it does not tell you how to build a system.

Konflux is the opinionated layer on top:

The Build-Test-Release Workflow

Once Konflux is installed and a component is onboarded, the full cycle looks like this:

1. Code push — developer pushes to main or opens a pull request on the testrepo fork
2. Pipelines-as-Code triggers a PipelineRun — Build Service reads the .tekton/ pipeline files from the repository and fires a PipelineRun in the tenant namespace
3. Build pipeline runs — init → clone → prefetch → buildah → build-image-index → SAST → Clair → ClamAV → rpms-signature-scan → apply-tags → push-dockerfile
4. Tekton Chains signs the image — after the PipelineRun completes, Chains uses the cluster’s internal cosign key to sign the image digest and attach a SLSA v0.2 provenance attestation
5. Snapshot is created — Integration Service automatically creates a Snapshot CR capturing the component’s built image digest
6. Integration tests run — the IntegrationTestScenario triggers a test pipeline that runs the built image as a Kubernetes Job and asserts the expected output
7. Release fires automatically — with auto-release: "true" on the ReleasePlan, Release Service creates a Release CR once the Snapshot passes all tests
8. Release pipeline validates and promotes — Enterprise Contract validates the image, then skopeo copies it to the staging registry and tags it as :stable

Running It on CRC (OpenShift Local)

I ran this entire setup on a Silicon Mac using CRC — as documented in my CRC setup guide. CRC (CodeReady Containers / OpenShift Local) gives you a single-node OpenShift 4 cluster that runs locally. Konflux installs on it cleanly with one script.

One important caveat for arm64 / Silicon Mac users: the multi-architecture build pipeline requires the Multi-Platform Controller, which provisions remote VMs for native arm64/s390x builds. This controller is not included in a CRC install. For everything else — building, testing, signing, releasing — CRC works perfectly. The workaround for multi-arch on CRC is to use the standard pipeline-docker-build-oci-ta bundle with skip-checks: "true" (scan images are amd64-only), which builds natively on the arm64 CRC node.

What the Repository Covers

The konflux-pipeline-blueprints repository is structured as 10 numbered directories, each mapping to one topic. Every directory has a README.md with prerequisites and expected outcomes, plus an interactive shell script that prompts for all required values:

• 01 — Install Konflux on OCP 4: Clone the official repo, run deploy-konflux-on-ocp.sh, wait for the Konflux CR to reach Ready=True, verify all namespaces.
• 02 — GitHub App & Quay.io Registry: Create a GitHub App with webhook secret, deploy the pipelines-as-code-secret to three namespaces, configure regcred for image push access.
• 03 — Onboard an Application: Apply Application and Component CRs, merge the auto-generated .tekton/ PR from Build Service, observe the first PipelineRun.
• 04 — Build Pipeline Internals: Inspect every task’s logs, extract the IMAGE_DIGEST result, download the SBOM with cosign, verify the image signature and SLSA attestation.
• 05 — Bundle-Based Pipeline: Replace the verbose inline pipelineSpec with a 50-line pipelineRef pointing to the pinned pipeline-docker-build-oci-ta OCI bundle. Understand the skip-checks parameter and when to use it.
• 06 — Pipeline as Code: Keep the inline pipelineSpec to add custom tasks — print-build-summary on push, pr-build-summary on pull requests. Understand PaC CEL annotations, cancel-in-progress, and max-keep-runs.
• 07 — Snapshots & Integration Tests: Apply RBAC for the integration runner, create an IntegrationTestScenario, watch the Integration Service trigger a test pipeline that runs the built image as a Kubernetes Job.
• 08 — Release Planning & Gating: Configure ReleasePlan, ReleasePlanAdmission, and create the EnterpriseContractPolicy by copying the cluster default. Commit the release pipeline and watch an auto-release promote the image to the staging registry.
• 09 — Enterprise Contract & SLSA: Install the ec CLI, extract the Chains public key, export the EC policy to a YAML file, run ec validate image, verify the cosign signature and decode the SLSA provenance attestation payload.
• 10 — Multi-Architecture Builds: Replace the single-arch push pipeline with pipeline-docker-build-multi-platform-oci-ta, watch three build-images TaskRuns appear simultaneously for amd64/arm64/s390x, verify the OCI Image Index with skopeo inspect --raw.

Key Technical Learnings

Pipeline bundles vs inline pipelineSpec

The auto-generated .tekton/ files use an inline pipelineSpec — every task reference written out explicitly, 200+ lines. You can swap this for a pipelineRef to a pinned OCI bundle in ~50 lines. The bundle is a complete Pipeline resource and includes all the same checks. The trade-off: you cannot append custom tasks to a pipelineRef pipeline — that requires the inline approach. Always pin bundles by digest (@sha256:...), never by tag.

Enterprise Contract in the release pipeline

The task-verify-enterprise-contract:0.1 bundle task has an OPA v1.x compatibility issue that causes conftest to fail at compile time. The working approach is to use the quay.io/conforma/cli:latest image directly in an inline taskSpec with seven steps: write-snapshot → initialize-tuf → validate → detailed-report → summary → version → assert. With STRICT: "false", violations are logged but do not block the release. Switch to "true" once all EC rules pass.

Credential management in the release pipeline

Mounting regcred as a projected volume and setting DOCKER_CONFIG to that directory is the reliable approach. It avoids the Tekton cred-init permission race where /tekton/home/.docker/config.json ends up with the wrong permissions when steps run as different users. Pre-creating /tekton/home/.docker/ with mode 777 in the first step ensures all subsequent cred-init writes succeed.

cosign verify and 2>&1

Never pipe cosign verify ... 2>&1 | jq. cosign writes status/progress messages to stderr and the JSON payload to stdout. Merging them corrupts the JSON stream and produces Expecting value: line 1 column 1 (char 0). Pipe stdout only: cosign verify ... | jq .

Extracting image references after a release

After the release pipeline runs, the latest PipelineRun in the namespace is the release run — not the build run. The release pipeline does not expose IMAGE_URL/IMAGE_DIGEST as Tekton results. Instead, read the image reference from the post-release-actions task log: tkn pipelinerun logs ... | grep "Released image" | awk '{print $NF}'.

Getting Started

Everything you need is in the repository. Each script is interactive and cross-platform (macOS and Linux). Placeholder replacement uses perl -pi -e rather than sed -i to avoid the macOS/Linux syntax difference.

❯ git clone https://github.com/ay-garg/konflux-pipeline-blueprints
❯ cd konflux-pipeline-blueprints
# Follow directories in order
❯ cd 01-install-konflux-ocp && bash install.sh
❯ cd ../02-github-app-registry && bash deploy-github-secret.sh
# ... continue through each directory

For the complete guide with architecture diagrams, YAML file references, command explanations, and troubleshooting for every step, visit: ay-garg.github.io/konflux-pipeline-blueprints

Prerequisites Summary

• OpenShift Container Platform 4.20+ or CRC — see CRC setup guide
• oc CLI v1.31.4+, tkn, cosign v2.x, skopeo, jq, python3
• GitHub account with permission to create GitHub Apps and fork repositories
• Quay.io account with push access
• Cluster-admin role: oc auth can-i '*' '*' --all-namespaces must return yes

Resources

• 📖 Konflux Pipeline Blueprints — Full Interactive Guide
• 💾 GitHub Repository — YAMLs, scripts, READMEs
• 🔧 What is Tekton — The Kubernetes-Native CI/CD Engine
• 🖥️ Run OpenShift 4 Locally with CRC
• 📚 Official Konflux Documentation
• 🔗 Konflux GitHub Organization
• 📦 All Konflux Pipeline Bundle Definitions