Try   HackMD

Tekton Security Self-Assessment

Authors:

Security reviewers:

Table of contents

Metadata
Assessment Stage Incomplete
Software http://github.com/tektoncd/*, https://github.com/tektoncd-catalog/* - see [#projects] from details
Website https://tekton.dev
Security Provider No
Languages Go, JavaScript (Dashboard)
SBOM SBOMs and Release Verification

Projects

Tekton is made of a collection of projects, each hosted under the tektoncd GitHub organisation.

Tekton Services:

Tekton Tools:

Tekton Resources:

SBOMs and SLSA

The go.mod files for each component can be found in the root directory of each repo, linked in the projects section above. Tekton relies on "Dependabot" to keep go.mod files up to date. Tekton Dashboard relies on "Dependabot" to also keep its package.json and related package-lock.json files up to date.

Tekton projects, except for cli, are built using ko. Release files, attached to each release in GitHub, are made of Kubernetes manifests, which include link to container images, hosted on ghcr.io. When ko is excuted as part of the releases process:

For example, for a recent release of the Pipeline project:

Container images are also signed, the instructions about how to verify them are included along with each release.

Doc url
Org-wide SECURITY.md https://github.com/tektoncd/.github/blob/main/SECURITY.md
Default and optional configs Main installation and configuration options are available at https://tekton.dev/docs/installation/ and https://tekton.dev/docs/installation/additional-configs/. Additionally, each project includes a docs folder, with configuration documentation, as well as a config folder with the Kubernetes manifests, which include ConfigMaps and other configuration options passed to controllers.
Tekton Security Review, 2022, by "Trail of Bits" https://cd.foundation/blog/2022/08/26/tekton-security-review-completed/

Overview

Tekton is a powerful and flexible open-source framework for creating CI/CD systems, allowing developers to build, test, and deploy across cloud providers and on-premise systems.

Tekton provides building blocks for cloud-native CI/CD, allowing CI/CD pipelines to benefit from the scalability benefits of the cloud. Tekton based CI/CD workflows can benefit from the rich ecosystem of cloud-native tools for developing, managing, observing and securing cloud-native applications, applied to CI/CD workflows.

Background

Tekton defines various Kubernetes custom resources (CRDs), that let users define, trigger and execute CI/CD workflows in the form of Kubernetes workloads. Tekton core services (Pipeline, Triggers, Chains, Results) are implemented as controllers for those resources.

Tekton resources can be signed, verified and shared for reusability and embedding of an organization's best practices. Tekton provides a set of admission controllers for validating resources - custom admission controllers can be added thanks to other CNCF projects like Kyverno and OPA.

Tekton can both consume and produce CloudEvents, to implement event driven, scalable and decoupled workflows.

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

More details about Tekton software design and concepts are available in the project’s documentation. See the following pages for an overview of the architecture:

Actors

The core Tekton project is Pipeline, which provides the pipeline orchestration functionalities.
All other components are optional, and provide additional functionalities and improved user experience for Tekton users.

Tekton relies on the Kubernetes controller framework implemented by the Knative project.

Pipeline Project

The pipeline project is responsible for the orchestrating the execution of pipelines and tasks on top of Kubernetes, ensuring that they are validated and executed to completion.

In the diagram below, Tekton actors are identified as components with a purple border, which act on several Tekton and Kubernetes resources.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

Webhook Controller (Service): This controller includes the Kubernetes Adminission Controllers for the various CRDs defined in the project: Pipeline, Task, StepAction, PipelineRun, TaskRun, ResolutionRequest. It provides resource validation for the user when resources are applied to the Kubernetes cluster.

Triggers Project

Chains Project

Results Project

Operator Project

The Tekton Operator streamlines the deployment, management, and upgrading of Tekton components (Pipelines, Chains, Dashboard, Triggers) on Kubernetes. It introduces TektonConfig as a top-level Custom Resource, which orchestrates the creation and management of other Tekton components. Additionally, the Tekton Operator handles Tekton Pipelines upgrades while preserving user data.

Dashboard Project

The Dashboard project provides a web-based UI, surfacing the current status of Tekton resources on the cluster. It can optionally be configured to provide some limited control of these resources, such as the ability to manually trigger a PipelineRun or TaskRun, delete Tekton resources, or import new Tekton resources to a target namespace on the cluster.

CLI Project

Catalog Project

Actions

Pipeline Project

Triggers Project

Chains Project

Results Project

Operator Project

Dashboard Project

The Dashboard is a single page application (SPA), providing a web-based UI backed by a set of REST APIs and a WebSocket connection for real-time updates.

It is not exposed outside the cluster by default. Users may choose how to access it, whether via temporary / ad-hoc methods such as kubectl port-forward or kubectl proxy, or via more long-term use methods such as by configuring an Ingress or similar reverse proxy approach.

All requests to the Dashboard back-end to access Tekton or other Kubernetes resources are validated against CSRF and SameOrigin checks, to ensure only requests originating from the same domain are allowed. Any request failing these checks is rejected. Valid requests are proxied to the Kubernetes API server which applies RBAC and related checks against the request and any target resource(s).

The Dashboard's default configuration includes a limited read-only set of permissions configured for the Dashboard's own ServiceAccount and uses the associated token for authentication to the API server. Any Authorization header or related request headers will be passed on to the API server. This gives control over the token used for authentication to the API server, and can be used for example to allow a trusted authenticating proxy to perform user impersonation. Any such tokens are not stored or cached by the Dashboard and should be provided on every request if the default permissions are not desired.

A second deployment option is provided in each release, enabling read-write access to the relevant Tekton resources. This is achieved using an additional configuration flag on the deployment, and a modified set of roles with the added write-related permissions. It relies on the same RBAC approach described above. The additional flag signals to the web UI that any features relying on write permission can be displayed to the user, but this flag alone is not sufficient to grant permissions and must be coupled with the updated roles to enable the functionality.

CLI Project

Catalog Project

Goals

Non-Goals

Self-Assessment Use

Security Functions and Features

Critical

Security Relevant

Project compliance

Secure Development Practices

The security policies and development practices detailed below are based on open source guidelines and preliminary threat modeling.

Development Pipeline

Code Development

Tekton contributors are required to sign a CLA (either personally or via their company) to contribute code to Tekton. The CLA check is provided via EasyCLA.

Tekton contributors are required to enable two-factor authentication (2FA) for their GitHub account if they would like to join the Tetkon organisation: https://github.com/tektoncd/community/blob/b32b21007a746200f18569139f663cfa8750de82/process/contributor-ladder.md?plain=1#L92.

New maintainers are nominated by existing maintainers only and have clear requirements, responsibilities and privileges defined: https://github.com/tektoncd/community/blob/b32b21007a746200f18569139f663cfa8750de82/process/contributor-ladder.md#maintainer.

In terms of reviews and approvals, Tekton provides community-level standards for contribution: https://github.com/tektoncd/community/blob/main/standards.md.
Each Tekton project defines its own policy in terms of reviews and requirements for a PR to be merged; the minium requirement is an approval from a maintainer.

Builds and Releases

Tekton release policies are documented in the community repo: https://github.com/tektoncd/community/blob/main/releases.md.

Tekton projects create nightly builds, which are fully automated, and main/patch releases, which are mostly automated, they requires human input for triggering of the releases process and updating documents. The release process in each project is aligned to the community guidelines and is very similar for each of the Tekton's project. The release pipeline itself is defined in Tekton format.

Each project includes a tekton folder which contains the Tekton release pipeline and tasks, as well as the documentation. For example, for the "Pipeline" project:

Each project includes a releases.md file, that documents all main and patch releases, as well as supported and EOL releases. "Pipeline" project example: https://github.com/tektoncd/pipeline/blob/main/releases.md.

Tekton releases are signed using Tekton Chains and a key stored on GCP KSM system. Attestations are built by Tekton Chains in in-Toto format, and stored in Sigstore's immutable log (Rekor), where they can be retrieved to verify the shas of the images that are part of a release. Verification instructions are part of the automatically generated release notes.

The steps in the release pipelines are:

  • Relevant git repositories are cloned
  • Checks are performed to ensure a new release may not override an existing one
  • Build and unit tests are performed
  • Multi-architecture images are built and published
  • Release manifests are published

Tekton Chains watches Tekton resources. When it detects that a release pipeline has produced a new release, it automatically signs the container images, produces the attestation and publishes it to Sigstore.

Finally the release manager triggers the post release pipeline:

  • Pushes a tag to the git repository
  • Generates and publishes release notes

Communication Channels

The project communication channels are documented on the community repository: https://github.com/tektoncd/community/blob/main/contact.md.

The project uses mailing lists for asychronous communication such as announcements and pools. The mailing lists are also open for users and developers to post questions or comments.

A dedicated mailing list exists for reporting vulnerabilities: https://github.com/tektoncd/community/security/policy.

Tekton has its own slack account, with a publicly available invite link and several channels dedicated to the various projects within Tekton.

Ecosystem

Tekton is built on the existing Kubernetes framework, an open source project hosted by CNCF. Tekton integrates with a number of other open source projects:

  • CloudEvents: Tekton can emit CloudEvents and can trigger pipelines based on incoming CloudEvents
  • Sigstore, in-toto, SLSA: Tekton chains allows users to use keyless signing for provenance, produce attestations in in-toto format and implement SLSA 3 compliant build systems
  • OpenTelemetry, Jaeger, Prometheus: Tekton emits OpenTelemetry metrics and distributed traces that can be visualized through Prometheus and Jaeger

Tekton itself is used as a building block for several other open source projects, such as Shipwright, JenkinsX, Kubeflow Pipelines for Tekton (kfp), Automatiko, Konflux and more. See https://github.com/tektoncd/community/blob/main/adopters.md#open-source-projects for a more detailed list.

Security Issue Resolution

Responsible Disclosure Process

Tekton describes its vulnerability reporting and discloure process as part of its security policy (https://github.com/tektoncd/community/security/policy):

To report a security issue, please email the Tekton vulnerability management team at tekton-vmt[at]googlegroups.com with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.

Incident Response

Reported incidents are managed by the Tekton Vulnerability Management Team (VMT). The Tekton VMT discusses incidents reported via the mailing list or discovered via different channels in a dedicated private channel on slack.

The Tekton VMT then uses the tools available on GitHub to track the reporting, fix and responsible disclosure of vulnerabilities via Security Advisories (for example https://github.com/tektoncd/pipeline/security/advisories).

Appendix

Known Issues Over Time

CII Best Practices

Tekton projects that have achieved the "Passing" status:

The Tekton Results project has not passed in its code analysis section, and its CII badge is still in progress:

Case Studies

Last changed by 
 
CDFoundation
CDFoundation
1
220

Read more

CDEvents Working Group Meeting Notes

hackmd-github-sync-badge

May 19, 2025
CDEvents Implementation Working Group Meeting Notes

hackmd-github-sync-badge

May 13, 2025
CDF SIG-Best-Practices

Agenda in HackMD

Jul 24, 2024
CDF Interoperability SIG Meetings (sig-interoperability)

HacmKD documents

Jul 18, 2024
Read more from CDFoundation
Published on HackMD