Pipeline Service

Pipeline Service provides Tekton APIs and services to Konflux.

# Architecture Evolution

The Pipeline Service architecture has evolved from a specialized service to a simplified deployment model:

• Upstream Installations (e.g., konflux-ci installer): Deploy upstream Tekton directly
• Downstream Installations (e.g., Fedora Konflux cluster): Deploy the OpenShift Pipelines distribution of Tekton via OLM operator subscription

# Historical Context

See ADR-0001 (Replaced) and ADR-0009 (Implemented) for the evolution from the initial kcp-based architecture to the current operator-based deployment model.

# APIs and Services

Pipeline Service provides the following:

• Tekton APIs directly through its custom resource definitions.
• Container image signing and provenance attestations through Tekton Chains.
• Archiving of PipelineRuns, TaskRuns, and associated logs through Tekton Results.

Pipeline Service also exposes the following ingress points:

• Pipelines as Code controller: this is a Route that receives webhook events from source code repositories.
• Tekton Results API: this is an Ingress that serves Tekton Results data over a RESTful API. Clients authenticate with the same Bearer token used to authenticate Kubernetes requests.

# Deployment Configuration

For downstream installations using the OpenShift Pipelines operator, the deployment includes the following notable configurations (see ADR-0009):

• Tekton Triggers will be disabled entirely.
• The pruner (provided by the Pipelines operator) will be disabled in favor of pruning via Tekton Results.
• Pipelines as Code will link the results of pipeline tasks to an appropriate Konflux UI URL.

# Architecture

# Diagram

Legend:

• Blue: managed by Pipeline Service
• Yellow: not managed by Pipeline Service

# Tekton Pipelines

# Trusted Artifacts

Tasks in Konflux build pipelines use Trusted Artifacts to securely share files between tasks (see ADR-0036). This allows users to include custom Tekton Tasks in build pipelines without jeopardizing build integrity. Trusted Artifacts wrap files into archives stored in OCI registries, with checksums recorded as task results to ensure artifacts are not tampered with between tasks.

# Task Results Naming Conventions

Task results follow standardized naming conventions (see ADR-0030) including TEST_OUTPUT for test-like tasks and SCAN_OUTPUT for scan-like tasks.

# Pipeline Service Accounts

Build Service creates component-specific service accounts named build-pipeline-<component-name> for running build pipelines (see Build Service documentation). This per-component approach provides better isolation and follows the principle of least privilege.

Historical Note: Previously, a shared appstudio-pipeline service account was used across all components in a namespace (see ADR-0025). The Pipeline Service component created the appstudio-pipelines-scc ClusterRole, and the CodeReadyToolchain platform created the appstudio-pipelines-runner ClusterRole and appstudio-pipeline ServiceAccount on tenant namespaces. This shared service account approach has been replaced by the current per-component model.

# Tekton Chains

# Signing Secret

The signing secret is unique to each cluster, and is a long lived secret. Rotating the secret is extremely disruptive, as it invalidates any artifact that was built using that secret.

Moving to keyless signing would solve the issue and would be the long-term solution.

The public-key is stored in openshift-pipelines namespace as a Secret named public-key. The secret is readable by all authenticated users to allow them to verify signed artifacts.

# Tekton Results

# Storage

AWS RDS and S3 are used to handle the storage needs of Tekton Results.

# Pipeline as Code

# Webhook Configuration

As of the workspace deprecation decision (see ADR-0039), Konflux follows a single-cluster design. Organizations operating multiple Konflux clusters should register a separate GitHub Application for each cluster. Each cluster’s Pipelines as Code controller receives webhooks directly from its dedicated GitHub Application.

Historical Note: Previously, multi-cluster deployments used Sprayproxy (ADR-0031, now Replaced) to fan out webhook requests from a single GitHub Application to multiple member clusters. This is no longer used.

# Secret management

The secrets for the GitHub Application are stored in Vault, and synchronized as an ExternalSecret. The refresh rate for the synchronization is aggressive so that rotating the secrets do not generate too long of an outage.

# Repositories

As of August 2024, Konflux no longer uses the deprecated Pipeline Service repository as a base for Tekton-related configuration.

Konflux now deploys Tekton components directly from their respective upstream repositories:

• Tekton Pipelines
• Tekton Chains
• Tekton Results
• Pipelines as Code

For downstream installations using OpenShift Pipelines, the operator is deployed via OLM subscription rather than through a centralized pipeline-service repository.