Trusted Tasks and Trusted Artifacts

Konflux uses "trusted tasks" to ensure secure and compliant task execution in build pipelines. There are two different ways that the pipeline is considered trusted:

Original (Non-Trusted Artifact) Pipelines.
Trusted Artifact Pipelines.

1. Original (Non-Trusted Artifact) Pipelines

Conforma requires that all Konflux pipelines use only tasks with the recorded provenance in the trusted Task list. See also the "Trusted Task" release and policy rules where this list is used.

The list of trusted Tasks is time based. A Task that is trusted today is not necessarily trusted tomorrow. The trusted Task list may contain bundles that are "too old" and no longer trusted. The reason for this behavior is to allow users a certain period of time to upgrade to a newer version of the Task.

Any record in the trusted Task List with an effective date in the future, and the record with the most recent effective date not in the future are trusted. For example, consider a list that includes the following trusted tasks:

a, effective on 2022-10-23
b, effective on 2022-10-22
c, effective on 2022-10-20
d, effective on 2022-10-19

If today is 2022-10-21, then the Tasks a, b, and c are trusted, while d is not.

Even when using a Task recorded in the trusted Task list, some policy rules may emit a warning if the reference used is not the latest one on the list. This is an attempt to notify users that although there are no violations today, an update is required for continued compliance. In the example above, using b or c would result in such a warning.

The process of adding Tasks to the list of trusted Tasks is described here.

1.1. Example Structure

The structure of the trusted Task list is best illustrated by an example:

task-bundles: (1)
  registry.io/org/task-bundle:
    - digest: sha256:...
      effective_on: "2023-05-14T00:00:00Z"
      tag: latest
trusted_tasks: (2)
  git+https://gitforge.io/org/tasks.git//tasks/my-task/0.1/my-task.yaml: (3)
    - effective_on: "2023-05-14T00:00:00Z" (4)
      expires_on: "2024-05-14T00:00:00Z" (5)
      ref: 3672a... (6)
  oci://registry.io/org/task-bundle:latest: (3)
    - effective_on: "2023-05-14T00:00:00Z" (4)
      expires_on: "2024-05-14T00:00:00Z" (5)
      ref: sha256:... (6)

1	Legacy format for tracking acceptable bundles, here only for backward compatibility. Will be removed entirely in future.
2	Trusted Tasks list in the new format, containing:
3	Provenance URI, i.e. where the Task can be retrieved from
4	The effective on time
5	The expires on time
6	Unique reference of the Task within the provenance URI (git commit id or image digest)

2. Trusted Artifact Pipelines

Trusted Artifacts is the current approach to securely share files between Tekton tasks in Konflux, especially for custom task use without compromising build integrity.

This approach allows users to include their own Tekton tasks (e.g. unit tests) in a secure and verified way.

Inspired by TEP-0139, this implementation acts as a stop-gap until full upstream support is available.

2.1. How It Works

A Task that creates a Trusted Artifact wraps files into an archive.
The archive location and checksums are exposed via task results.
A Task that consumes the artifact verifies the checksum and unpacks it into a secure emptyDir volume.

Artifacts are shared via OCI registries (e.g. quay.io), not via Persistent Volume Claims (PVCs).

Also, note that when using Trusted Artifacts, only the tasks that directly impact the pipeline’s output must be in the trusted task list. Typically this is the git clone task, the prefetch dependencies task, and the build tasks.

In contrast, when using the non-trusted artifacts pipeline, every task in the pipeline must be in the trusted task list.

2.2. Naming Conventions and Rules

Producing tasks must use result names ending in _ARTIFACT (e.g. SOURCE_ARTIFACT).
Consuming tasks must use parameter names ending in _ARTIFACT.
These tasks must NOT use general-purpose workspaces for file sharing.
Workspaces are allowed for non-sharing purposes, like mounting Secrets.

2.3. Migration and Task Variants To aid transition:

New variants of standard tasks exist, using the suffix -oci-ta, e.g. git-clone-oci-ta.
New tasks with fresh functionality that use Trusted Artifacts need not follow the suffix naming convention.

3. Summary

The Trusted Tasks List enforces a time-based, curated system to approve and validate tasks for pipeline security.
Non-Trusted Artifact Pipelines require every task in the pipeline to be included in the trusted task list, enforcing stricter end-to-end compliance.
Trusted Artifact Pipelines offer flexibility: only tasks that directly impact the pipeline’s output (e.g., git clone, prefetch dependencies, build tasks) must come from the trusted task list.