Module 2: Getting started with Konflux

Learning objectives

By the end of this module, you will be able to:

  • Create an application in Konflux

  • Onboard a component from a Git repository

  • Understand how Konflux automatically configures build pipelines

  • Configure release settings for your application

  • Trigger a secure build and release pipeline

  • Verify signed container images with SLSA Level 3 provenance

  • Analyze SBOMs and vulnerability reports

Introduction

In this module, you will use the Konflux UI to create an application, onboard a component from GitLab, and trigger a complete build-sign-release workflow.

This is where TechCorp’s platform engineering work pays off — developers can now build secure, signed container images automatically!

Exercise 1: Create an application

In this exercise, you will create your first application in Konflux.

Access Konflux UI

  1. Open the Konflux UI in your browser (if not already open):

    KONFLUX_URL="https://$(oc get route -n konflux-ui -l konflux.konflux-ci.dev/component=ui,konflux.konflux-ci.dev/owner=konflux-ui -o jsonpath='{.items[0].spec.host}')"
echo "Konflux UI: $KONFLUX_URL"

  2. Ensure you are logged in and see the landing page.

Create application

  1. In the left menu, click on Namespaces .

  2. Select default-tenant.

  3. Click Create an application.

  4. Enter an application name:

    sample-application

    Application names must be lowercase with hyphens. For example: techcorp-payment-service

  5. Click Create.

  6. You should see your new application page with:

    • Application name at the top

    • "Add component" button

    • Empty components list

Verify

✓ Application created successfully
✓ Application name appears in UI
✓ Application page displays with "Add component" option

An application in Konflux represents "a logical grouping of one or more components that are built, tested, and released together." For example, a microservices application might have multiple components (frontend, backend, database) that are deployed as a unit.

Exercise 2: Add a component

In this exercise, you will onboard your first component by connecting a Git repository.

Prepare the sample repository

For this workshop, you will use the Konflux sample component repository available in the tsf group of the local GitLab repository.

Add component in Konflux

  1. From your application page, click Actions > Add component.

  2. Enter your Git repository URL:

    {gitlab_url}/tsf/sample-component-golang.git

  3. Toggle Should the image produced be private to the off position.

  4. Select the branch to build (default: main).

  5. Konflux automatically detects:

    • Dockerfile location (if present)

    • Build strategy (Dockerfile, Buildpacks, etc.)

    • Pipeline template to use

  6. Click Add component.

The webhook is created and configured in the GitLab repository.

Understand what happens

When you create a component, Konflux automatically:

  1. Sends a pull request to your repository adding .tekton/ directory

  2. Creates pipeline definitions that trigger on push and pull request events

  3. Configures integration tests that run after builds

  4. Sets up CI checks in your repository

Do not merge the pull request yet! You need to configure release settings first.

View the merge request

  1. Go to your GitLab repository.

  2. Click Merge requests.

  3. You should see a merge request from Konflux adding .tekton/ directory:

    Title: Add Konflux pipeline definitions
Files changed: .tekton/pull-request.yaml, .tekton/push.yaml

  4. Do not merge the PR until Exercise 4'

  5. Review the files.

  6. After a few seconds, the CI will trigger the Konflux pipelines. You can monitor their progress, which should take about 10m on the first run.

Verify

✓ Component created in Konflux
✓ Merge request sent to GitLab repository
✓ .tekton/ directory added with pipeline definitions
✓ Pipeline files visible in PR

The .tekton/ directory contains Tekton PipelineRun definitions that are triggered by the GitLab webhook. These pipelines build, test, and sign your container images automatically.

Exercise 3: Configure release settings

In this exercise, you will configure release settings so your application can be deployed after builds.

Release configuration requires cluster-admin access. This step simulates what a platform engineer would do to enable releases for developers.

Create release configuration

For this workshop, we’ll use a simplified approach. In a production environment, you would create ReleasePlan and ReleaseStrategy custom resources.

  1. Download the script from the konflux-cli namespace:

    oc get configmap setup-release \
  -n konflux-cli \
  -o jsonpath='{.data.setup-release\.sh}' > setup-release.sh
chmod +x setup-release.sh

  2. Run the script for your application (replace placeholders):

    ./setup-release.sh -a <application_name> -t <tenant-namespace> -m <managed-namespace>

Use ./setup-release.sh -h for all options. This creates the release plan, release policy, and release pipeline resources expected for your Konflux version.

Verify

✓ setup-release.sh downloaded and executable
✓ Script ran without errors for your application and namespaces
✓ ReleasePlan Custom Resources created

In production, release plans can target different environments (dev, staging, prod) and include approval gates, policy checks, and deployment strategies.

Exercise 4: Trigger the release build pipeline

In this exercise, you will trigger your first secure release build by merging the Konflux pull request.

Merge the pull request

  1. Go back to your Git repository.

  2. Open the Konflux onboarding pull request.

  3. Merge the pull request.

Watch the pipeline run

  1. Return to the Konflux UI.

  2. Navigate to your application → Components.

  3. You should see your component with:

    • Build status: In Progress

    • Pipeline run: Active

  4. Click on the component name to see details.

  5. Click on the pipeline run to watch it execute in real-time.

Understand the build process

The pipeline performs these steps:

  1. Clone — Fetches source code from Git

  2. Build — Builds container image using Dockerfile

  3. Sign — Signs image with Red Hat Trusted Artifact Signer (Fulcio certificate)

  4. Generate SBOM — Creates Software Bill of Materials

  5. Scan — Scans image for vulnerabilities

  6. Push — Pushes signed image to Quay

  7. Integration tests — Runs automated tests against the image

Wait for completion

  1. The pipeline takes approximately 5-10 minutes to complete.

  2. When finished, you should see:

    • Build status: Succeeded (green checkmark)

    • Image: Link to Quay repository

    • Signature: Verified

Verify

✓ Pull request merged successfully
✓ Pipeline triggered automatically
✓ Build completed successfully
✓ Image pushed to Quay

Exercise 5: Verify the signed image

In this exercise, you will verify that your container image was signed with Red Hat Trusted Artifact Signer and has SLSA Level 3 provenance.

View the image in Quay

  1. From the Konflux UI, click the Image link in your component.

  2. You will be redirected to Quay showing your new repository and image.

  3. Note the image tag (typically a git commit SHA).

View signature with cosign

  1. From your terminal, download cosign from the cluster:

    tas_host=$(oc get route -A -l "app.kubernetes.io/part-of=trusted-artifact-signer,app.kubernetes.io/component=client-server" -o jsonpath='{.items[0].spec.host}')
ARCH=$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/')
curl --fail --location --output cosign.gz --show-error --silent https://${tas_host}/clients/linux/cosign-${ARCH}.gz
gunzip cosign.gz
chmod +x cosign

  2. Verify the metadata attached to the image using cosign:

    IMAGE="<image-reference>"
./cosign tree $IMAGE

    Replace <image-reference> with your image (for example <quay-url>/<org>/<repo>@sha256:…​).

    Expected output:

    📦 <quay-url>/<org>/sample-component-golang@sha256:...
├── 💾 attestations
│   └── ...
└── 🔐 signatures
    └── ...

  3. Configure cosign to use the TUF server deployed on the cluster:

    TUF_HOST=$(oc get route -A -l "app.kubernetes.io/part-of=trusted-artifact-signer,app.kubernetes.io/component=tuf" -o jsonpath='{.items[0].spec.host}')
curl -sSfL -o /tmp/root.json https://$TUF_HOST/root.json
./cosign initialize \
  --mirror=https://$TUF_HOST \
  --root=/tmp/root.json

  4. View the signature details:

    ./cosign verify $IMAGE \
  --certificate-identity-regexp '.*' \
  --certificate-oidc-issuer-regexp '.*'

  5. View the attestation details:

    REKOR_HOST=$(oc get route -A -l "app.kubernetes.io/part-of=trusted-artifact-signer,app.kubernetes.io/component=rekor-server" -o jsonpath='{.items[0].spec.host}')
./cosign verify-attestation $IMAGE \
  --certificate-identity-regexp '.*' \
  --certificate-oidc-issuer-regexp '.*' \
  --rekor-url="https://$REKOR_HOST" \
  --type=slsaprovenance

  6. View the SBOM details:

    REKOR_HOST=$(oc get route -A -l "app.kubernetes.io/part-of=trusted-artifact-signer,app.kubernetes.io/component=rekor-server" -o jsonpath='{.items[0].spec.host}')
./cosign verify-attestation $IMAGE \
  --certificate-identity-regexp '.*' \
  --certificate-oidc-issuer-regexp '.*' \
  --type=spdxjson

Understand SLSA provenance

SLSA (Supply-chain Levels for Software Artifacts) is a framework for ensuring artifact integrity.

Your build produces SLSA Level 3 provenance which records:

  • Who built the image (build system identity)

  • When it was built (timestamp)

  • How it was built (pipeline definition, steps)

  • What source code was used (Git commit SHA)

This provenance is signed and attached to the image, providing an immutable audit trail.

Verify

✓ Image visible in Quay registry
✓ Image has cryptographic signature
✓ Signature verified with cosign
✓ SLSA provenance and SBOM attached to image

Exercise 6: View the release

In this exercise, you will view the automated release created after your build succeeded.

Access releases tab

  1. Return to the Konflux UI.

  2. Navigate to Applications-Your_application and select the Releases tab on the top menu.

  3. You should see a release for your application:

    • Name: Click on this link for information about the release

    • Status: Succeeded

    • Release Snapshot: Click on this for information about the event that triggered the release and the revision of the code that was used to build it.

View release details

  1. Click on the release to view details:

    • Image: Full image reference in Quay

    • Signature: Verification status

    • Tests: Integration test results

    • Provenance: SLSA attestation

  2. The release confirms that:

    • Build completed successfully

    • Image was signed with Red Hat Trusted Artifact Signer

    • Integration tests passed

    • Image was pushed to Quay

View policy validation information

  1. From the application’s Releases tab, click on the Name link

  2. Select the Pipeline runs tab

  3. Click on the name of the pipeline run to access details of the pipeline

  4. Select the Security tab to browse the results of the validation against the Conforma policy

Verify

✓ Release created automatically after build
✓ Release shows image, signature, and tests
✓ All verification checks passed

Exercise 7: Analyze the SBOM

In this exercise, you will view the Software Bill of Materials and vulnerability report generated by Red Hat Trusted Profile Analyzer.

Access RHTPA UI

  1. Open the Red Hat Trusted Profile Analyzer UI in your browser:

    RHTPA_URL="https://$(oc get route -n tsf-tpa -l app.kubernetes.io/component=server,app.kubernetes.io/instance=trustedprofileanalyzer -o jsonpath='{.items[0].spec.host}')"
echo "RHTPA UI: $RHTPA_URL"

  2. Authenticate with your OpenShift Container Platform credentials (same as Konflux).

View SBOM

  1. In the RHTPA UI, navigate to SBOMs or Components.

  2. Find your component: sample-component-golang

  3. Click on the component to view its SBOM.

  4. The SBOM shows:

    • All packages included in the image

    • Dependencies and their versions

    • Licenses for each component

    • Package sources (Go modules, OS packages, etc.)

View vulnerabilities

  1. Click on the Vulnerabilities tab.

  2. You should see a list of known CVEs affecting packages in your image.

  3. For each vulnerability:

    • CVE ID — Common Vulnerabilities and Exposures identifier

    • Severity — Critical, High, Medium, Low

    • Affected package — Which package has the vulnerability

    • Fixed version — Version that fixes the issue

Understand the value

The SBOM and vulnerability data allow TechCorp to:

  • Track all software in their supply chain

  • Identify vulnerable components quickly

  • Remediate by updating to patched versions

  • Comply with security policies and regulations

Verify

✓ Accessed RHTPA UI successfully
✓ Viewed SBOM for your component
✓ Identified packages and dependencies
✓ Reviewed vulnerability scan results

Learning outcomes

Let’s verify what you’ve accomplished in this module:

  • ✓ You created an application in Konflux

  • ✓ You onboarded a component from a Git repository

  • ✓ You configured release resources with setup-release.sh

  • ✓ You merged Konflux’s pull request to enable pipelines

  • ✓ You completed build, integration, and release flows in the UI

  • ✓ You verified the signed container image with cosign

  • ✓ You viewed SLSA Level 3 provenance

  • ✓ You analyzed the SBOM and vulnerability scan in RHTPA

  • ✓ You confirmed the release record

Summary

In this module, you successfully built your first secure application with TSF:

  • Created an application and added a component from Git

  • Triggered a build pipeline that automatically signed the image

  • Verified cryptographic signatures and SLSA provenance

  • Analyzed the SBOM and vulnerability report

  • Viewed the automated release to Quay

You now have a complete secure software supply chain in action!

Next steps

Now that you’ve completed the workshop, consider:

  • Onboarding your own applications — Replace the sample component with your actual projects

  • Customizing pipelines — Edit .tekton/ files to add custom build steps

  • Implementing policies — Use Conforma to enforce security policies

  • Configuring multi-environment releases — Set up dev, staging, and prod targets

  • Automating deployments — Integrate with ArgoCD or OpenShift GitOps

Click Next for the workshop conclusion. For help with issues, see Appendix D: Troubleshooting.