Tekton Security Self-Assessment

--- tags: Tekton --- # Tekton Security Self-Assessment Authors: Security reviewers: ## Table of contents - [Metadata](#metadata) - [Security links](#security-links) - [Overview](#overview) - [Actors](#actors) - [Actions](#actions) - [Background](#background) - [Goals](#goals) - [Non-goals](#non-goals) - [Self-assessment use](#self-assessment-use) - [Security functions and features](#security-functions-and-features) - [Project compliance](#project-compliance) - [Secure development practices](#secure-development-practices) - [Security issue resolution](#security-issue-resolution) - [Appendix](#appendix) ## 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](#sboms) | ### Projects Tekton is made of a collection of projects, each hosted under the `tektoncd` GitHub organisation. Tekton Services: - http://github.com/tektoncd/pipeline - http://github.com/tektoncd/triggers - http://github.com/tektoncd/chains - http://github.com/tektoncd/results Tekton Tools: - http://github.com/tektoncd/operator - http://github.com/tektoncd/cli - http://github.com/tektoncd/dashboard Tekton Resources: - http://github.com/tektoncd/catalog - http://github.com/tektoncd-catalog/\* ### 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](#projects) 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`](https://github.com/ko-build/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: - it build and publishes the container images to ghcr.io, using [Chainguard images as a base image](https://github.com/tektoncd/pipeline/blob/e34b540bfabee8c48973b6bf722a478d9542cb85/tekton/publish.yaml#L127) - it updates manifests with the images it built - it creates SBOM files, which are published to ghcr.io next to the images For example, for a recent release of the Pipeline project: - Release on GitHub: https://github.com/tektoncd/pipeline/releases/tag/v0.68.0 - Release file: https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.68.0/release.yaml - Images: `curl -L https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.68.0/release.yaml | grep 'image: '` - Controller Image: [ghcr.io/tektoncd/pipeline/controller-10a3e32792f33651396d02b6855a6e36:v0.68.0@sha256:**b09f78ea0b73e944c1a002fba65fed7853a84bd237fe0cff610b65654e5bb7b9**](ghcr.io/tektoncd/pipeline/controller-10a3e32792f33651396d02b6855a6e36:v0.68.0@sha256:b09f78ea0b73e944c1a002fba65fed7853a84bd237fe0cff610b65654e5bb7b9) - SBOM: [ghcr.io/tektoncd/pipeline/controller-10a3e32792f33651396d02b6855a6e36:v0.68.0?tag=sha256-**b09f78ea0b73e944c1a002fba65fed7853a84bd237fe0cff610b65654e5bb7b9**.sbom](ghcr.io/tektoncd/pipeline/controller-10a3e32792f33651396d02b6855a6e36:v0.68.0?tag=sha256-b09f78ea0b73e944c1a002fba65fed7853a84bd237fe0cff610b65654e5bb7b9.sbom) Container images are also signed, the instructions about how to verify them are included along with each release. ### Security links | 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. ![tekton-architcture-components](https://hackmd.io/_uploads/S1lPxIx4lg.png) 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: * https://tekton.dev/docs/concepts/concept-model/ * https://tekton.dev/docs/concepts/overview/ * https://tekton.dev/docs/concepts/supply-chain-security/ * https://tekton.dev/docs/triggers/ ### 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](https://knative.dev) project. #### Pipeline Project The pipeline project is responsible for 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. ![tekton-architcture-Pipeline](https://hackmd.io/_uploads/HyRpjOjYJe.png) **Webhook Controller** (Service): This controller includes the Kubernetes Admission 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. **PipelineRun Controller**: This controller monitors `PipelineRun` resources and is responsible for orchestrating the execution of pipelines. When a `PipelineRun` is created, the controller resolves the referenced `Pipeline` and all related `Tasks`, manages execution order and dependencies as defined in the pipeline graph, and creates corresponding `TaskRun` resources. It tracks execution progress, aggregates results, and updates the `PipelineRun` status to reflect success, failure, or cancellation. **TaskRun Controller**: This controller monitors `TaskRun` resources and manages their lifecycle. Upon creation of a `TaskRun`, it resolves the referenced `Task`, creates a Kubernetes Pod to execute the defined steps, and tracks the execution status. It updates the `TaskRun` with results and completion state, handling retries and failures as needed. **Entrypoint**: Entrypoint is a small binary injected into each step container by Tekton. It ensures proper sequencing and execution of step commands, manages signal handling, and serializes step results so they can be collected by the controller. Entrypoint also coordinates file-based readiness between steps, ensuring that dependencies are respected before a step starts running. **Remote Resolution Controller**: This controller watches for `ResolutionRequest` CRDs, which are created by the `PipelineRun` and `TaskRun` controllers when a referenced resource uses a remote resolver. When a `ResolutionRequest` is created, the Remote Resolution Controller processes the request by fetching the remote resource, validating it, and updating the status of the `ResolutionRequest` with the resolution result. **Events Controller**: The Events Controller is responsible for sending `CloudEvents` when the status of Tekton resources such as `PipelineRun`, `TaskRun`, or `Run` changes. It emits events like `started`, `running`, `succeeded`, or `failed` to a configured sink, enabling integrations with external systems and event-driven workflows. #### Triggers Project Tekton Triggers is a Tekton component that allows you to detect and extract information from events from a variety of sources and deterministically instantiate and execute `TaskRuns` and `PipelineRuns` based on that information. Tekton Triggers can also pass information extracted from events directly to `TaskRuns` and `PipelineRuns`. You install Tekton Triggers on your Kubernetes cluster as an extension to Tekton Pipelines. Its actors are the controller service and the EventListentr sink Pod that runs on the Kubernetes cluster. They process the following CRDs: `EventListener`, `Trigger`, `TriggerTemplate`, `TriggerBinding`, `ClusterTriggerBinding`, `Interceptor` and `ClusterInterceptor`. **EventListener Controller**: The EventListener Controller watches for `EventListener` custom resources and ensures that each one has a corresponding Kubernetes objects running in the cluster. **EventListener Sink Pod**: The EventListener sink pod listens for events on an addressable HTTP endpoint defined in the `EventListener` Custom Resource. The Custom Resource specifies which `Trigger` resources to invoke when an event arrives, and how event data should be processed before instantiating Tekton resources like `PipelineRun` or `TaskRun`. The `EventListener` can reference multiple `Trigger` definitions, which in turn use `TriggerBinding`, `TriggerTemplate`, and optionally `Interceptor` resources to extract parameters, transform data, and define what gets created in response to each event. This abstraction allows users to declaratively connect any external system to Tekton pipelines, enabling event-driven CI/CD workflows. #### Chains Project The Tekton chains project is responsible to watch Pipeline's objects (`TaskRun`, `PipelineRun`), and once they complete, take a snapshot to one or more standard payload formats, sign them and store them somewhere. There is only one actor in this project, and it is the chains controller, responsible for everything (watching, signing and storing). **Chains Controller**: The Chains Controller is responsible for monitoring completed `TaskRun` and `PipelineRun` resources in the cluster. When a run finishes, the controller captures a snapshot of its state, formats it into one or more supported payload types (such as in-toto, SLSA, or SPDX), signs the payload with a configured cryptographic key (supporting various signing backends), and stores the signed result in a destination like an OCI registry, transparency log, or cloud storage. This automated process ensures that every pipeline or task execution generates a tamper-evident, verifiable record, supporting strong supply chain security guarantees for Tekton workloads. #### Results Project The Tekton Results project provides long-term storage and query capabilities for Tekton Pipeline execution data. It is designed to persist records of TaskRun and PipelineRun executions, making this data available for auditing, compliance, and analytics beyond the lifecycle of the original Kubernetes resources. The actors are the Results API Server, Results Watcher Kubernetes Controller and the Result Retention Policy Agent. **Results API Server**: The Results API Server exposes gRPC and REST APIs for creating, updating, and querying `Result` and `Record` resources. It acts as the gateway for users and systems to interact with long-term execution data, handling authentication, authorization, filtering, ordering and pagination. **Results Watcher Controller**: The Results Watcher Controller monitors the cluster for changes to Tekton `TaskRun` and `PipelineRun` resources. When it detects new or updated runs, it collects execution data and pushes it to the API server, ensuring all relevant results are persisted for future querying and auditing. **Result Retention Policy Agent**: The Result Retention Policy Agent automatically deletes or archives data that exceeds retention limits. #### Operator Project The Tekton Operator streamlines the deployment, management, and upgrading of Tekton components (Pipelines, Chains, Dashboard, Triggers, Results) 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 The CLI project provides a command-line tool to interact mainly with the Pipeline's API surface (`Task`, `Pipeline`, `StepAction`, `PipelineRun`, `TaskRun`, …). #### Catalog Project The catalog project holds a set of reusable Pipeline's object definitions (`Task`, `Pipeline`, `StepAction`) that designed to be re-usable. ### Actions All Kubernets controllers across the various projects (Pipeline, Triggers, Chains, Results, Operator) rely on Kubernetes' RBAC and security features to control access to various Kubernets API and to secure #### Pipeline Project Webhook controllers are built on top of [Knative's Webhooks](https://pkg.go.dev/knative.dev/pkg/webhook#section-readme), which they rely on to provision and refresh self-signed certificates used by the webhook to expose an HTTPS API towards the Kubernets API server. #### 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 The Tekton CLI relies on Kubernets authentication and authorization mechanism to let users inspect, create, modify and delete Tekton resources in a Kubernetes cluster. The Tekton CLI can be used to sign resources using a local key or one of the supported KMS systems. #### Catalog Project The catalog project stores a set of reusable Tekton components, such as StepActions, Tasks and Pipelines. The actions implemented by the each Tekton component vary from resource to resource. The catalog project provides [recommendations](https://github.com/tektoncd/catalog/blob/main/recommendations.md) to resource authors about best practices, including avoiding priviledged containers. Several Tasks need credentials to perform the action they implement. Credentials are typically obtained through a Tekton Workspace, which at runtime is typically mapped to a Kubernetes secret of secret. [Tekton resources can be signed](https://tekton.dev/docs/pipelines/trusted-resources/), via the Tekton CLI. The Tekton catalog itself does not verify signatures. Signatures can be verified by the Tekton Pipeline controllers. ### Goals Tekton provides scalable, reusable and secure pipelines on top of Kubernets. Tekton provides the building blocks to let users build [SLSA3](https://slsa.dev/spec/v1.1/levels#build-l3) compliant build systems. The project mostly relies on [Kubernets security features](https://kubernetes.io/docs/concepts/security/), such as Secrets, RBAC, Pod Security standards and Adminission Controllers to let users build secure pipelines and control access to and execution of the pipelines. Tekton controllers include predefined roles that follow the principle of least access when granting access to cluster resources. Below some sub-project-specific security goals, in addition to the common ones listed above. #### Pipeline Project The goal of the Pipeline project is to let users build and run scalable, reusable and secure CI/CD workflows on top of Kubernetes. Tekton Pipeline resources can be signed, and users may define policies to control the execution of signed and unsigned resources. Tekton Pipeline may produce provenance data about artifacts produced by steps and tasks. Tekton pipeline providers [tools and guidelines](https://tekton.dev/docs/pipelines/auth/) for users to securely access resources like git repositories and container registries. #### Triggers Project The goal of the Triggers project is to let users run Tekton pipeline in response to events (HTTP/HTTPS triggers). Event interceptors can be used to validate and pre-process incoming events. #### Chains Project Tekton Chains provides integration with various cloud key management systems (KMS) and Sigstore to sign artifacts produced by Tekton pipelines, such as container images. Tekton Chains can produce provenance data, in in-Toto format and stored in Sigstore's Rekor, so that it may be possible to verify the build steps used to produced a certain artifact. #### Results Project Tekton Results provides long-term storage for Tekton's execution history. Tekton results gathers the execution history from the Kubernetes cluster, and exposes it to users via a secure API. Tekton results [relies on cluster tokens](https://github.com/tektoncd/results/blob/main/docs/api/README.md#authenticationauthorization) for authentication to its API. #### Operator Project The Tekton Operator manages the lifecycle of deployment of the various Tekton components. #### Dashboard Project The Tekton Dashboard project provides a graphical user interface to view and create Tekton resources. The Tekton dashboard can be configured as read-only, for public access, or fully features, for access to priviledged audiences. The Tekton dashboard provide [guidelines](https://github.com/tektoncd/dashboard/blob/main/docs/walkthrough/walkthrough-oauth2-proxy.md) about integrating with an oauth-proxy for authentication purposes. #### CLI Project The Tekton CLI project provides a command line based interface (`tkn`) for managing Tekton resources across the various sub-projects. Authentication and authorization to Kubernetes clusters are based on the same mechanism and configuration used for the Kubernetes CLI (`kubectl`). The Tekton CLI allows signing Tekton resources based on a local key file and integration with a few KMS systems. #### Catalog Project The Tekton Catalog projects provides a collection of reusable Tekton resources. ### Non-Goals Tekton is not a fully fletched CI/CD system, rather it provides the building blocks for creating one, giving adopters the flexibility to adapt the workflows to their needs with a powerful set of tools focused on scalability and security. While Tekton is very security minded, it does not implement from scratch security features, rather it integrates or incorporates security tools and libraries from the cloud-native ecosystem and beyond to provide its own security capabilities. ## Self-Assessment Use This self-assessment is created by the Tekton team to perform an internal analysis of the project’s security. It is not intended to provide a security audit of Tekton, or function as an independent assessment or attestation of Tekton’s security health. This document serves to provide Tekton users with an initial understanding of Tekton’s security, where to find existing security documentation, Tekton plans for security, and general overview of Tekton security practices, both for development of Tekton as well as security of Tekton. This document provides the CNCF TAG-Security with an initial understanding of Tekton to assist in a joint-assessment, necessary for projects under incubation. Taken together, this document and the joint-assessment serve as a cornerstone for if and when Tekton seeks graduation and is preparing for a security audit. ## Security Functions and Features ### Critical | Component | Applicability | Description of Importance | | --------- | ------------- | ------------------------- | | Kubernetes Infrastructure | Critical | Tekton is built upon Kubernetes, which is configured with security tools like RBAC, network policies, and secrets. | ### Security Relevant | Component | Applicability | Description of Importance | | --------- | ------------- | ------------------------- | | Code Signature Verification | Security Relevant | Tekton signs their releases with cosign to verify binaries, ensuring integrity and authenticity for users. | | Resource Verification | Security Relevant | Tekton allows user to sign their Tekton tasks and pipelines and define policies to disallow execution of tasks and pipelines that are unsigned or with invalid signatures. | | Artifacts | Security Relevant | Tekton provide users with tools to sign artifacts produced by tasks and pipelines, and to produce and sign provenance for auditing purposes. | ## Project compliance Tekton gives users the tools requires to create [SLSA3](https://slsa.dev/spec/v1.1/levels#build-l3) compliant build systems. ## 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](https://easycla.lfx.linuxfoundation.org/#/). 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: - `tekton` folder: https://github.com/tektoncd/pipeline/tree/main/tekton - Release docs: https://github.com/tektoncd/pipeline/blob/main/tekton/release-cheat-sheet.md 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 - Tekton Security Audit from 2022: https://cd.foundation/wp-content/uploads/sites/78/2022/08/Tekton-Report-Public-Final.pdf - Pipeline Security Advisories: https://github.com/tektoncd/pipeline/security/advisories?state=published - Dashboard Security Advisories: https://github.com/tektoncd/dashboard/security/advisories?state=published - ### CII Best Practices Tekton projects that have achieved the "Passing" status: - [Pipeline](https://www.bestpractices.dev/projects/4020): ![](https://www.bestpractices.dev/projects/4020/badge) - [Triggers](https://www.bestpractices.dev/projects/6527): ![](https://www.bestpractices.dev/projects/6527/badge) - [Chains](https://www.bestpractices.dev/projects/6408): ![](https://www.bestpractices.dev/projects/6408/badge) - [Dashboard](https://www.bestpractices.dev/projects/6543): ![](https://www.bestpractices.dev/projects/6543/badge) - [CLI](https://www.bestpractices.dev/projects/6510): ![](https://www.bestpractices.dev/projects/6510/badge) - [Operator](https://www.bestpractices.dev/projects/6548): ![](https://www.bestpractices.dev/projects/6548/badge) The Tekton Results project has not passed in its code analysis section, and its CII badge is still in progress: - [Results](https://www.bestpractices.dev/projects/10012): ![](https://www.bestpractices.dev/projects/10012/badge) ### Case Studies Tekton hosts a ["Tekton Friends"](https://github.com/tektoncd/friends/tree/main) repositories where various companies over time shared their interest and use cases with Tekton. Some examples: - [CloudBees](https://github.com/tektoncd/friends/tree/main/cloudbees) built their DevSecOps platform on top of Tekton - [Ozone](https://github.com/tektoncd/friends/blob/main/ozone/readme.md) leverages the Tekton framework to provide cloud native Continuous Delivery as-a-service - [Elastic](https://github.com/tektoncd/friends/blob/main/elastic/readme.md) is using Tekton Pipeline and Tekton CLI in build and release processes for the Elastic Stac - [Alibaba](https://github.com/tektoncd/friends/blob/main/alibaba/readme.md) uses Tekton to continuously deliver services across hybrid clouds Other companies use Tekton as well (non-exhaustive list): - Nubank used Tekton to [scale their CI/CD platform](https://www.youtube.com/watch?v=fW69GEOsE-Q) - [SolarWind used Tekton to secure their supply chain in the wake of the sunburst hack](https://www.youtube.com/watch?v=1-tMRxqMwTQ) - [Xebia uses Tekton for continuous deployment and DevSecOps compliance](https://www.youtube.com/watch?v=EsySdsPG5KQ) - [IBM](https://www.ibm.com/products/tekton) offers a Continuous Delivery Cloud Service [build on Tekton](https://cloudbootcamp.dev/devops/materials/10-IBM-Cloud-DevOps.pdf). IBM also uses Tekton as the basis of IBM Cloud's broadly adopted [internal DevSecOps pipelines](https://github.com/tektoncd/community/blob/main/adopters.md#end-users). - [RedHat](https://github.com/tektoncd/friends/blob/main/redhat/README.md) built [OpenShift Pipelines](https://docs.redhat.com/en/documentation/red_hat_openshift_pipelines/1.18) on Tekton to provide CI/CD services for the OpenShift platform. Several companies benefit from Tekton through OpenShift. Some examples: - [Mastercard](https://www.youtube.com/watch?v=mVR_LKp2Jxk&t=883s) - [Ford](https://www.redhat.com/en/blog/fords-community-first-approach-cicd) - [Lloyd Banking Group](https://www.youtube.com/watch?v=HfsJqqjmiZo&t=73s) - [Airbus Elicopters](https://www.redhat.com/rhdc/managed-files/rh-airbus-helicopters-case-study-314230pr-202306-en.pdf) - [Swiss Federal Railways](https://www.youtube.com/live/SpRSndQCl2I?si=S-rk_B_ypGuHpg7_&t=5898) Finally, the [Tekton Adopters](https://github.com/tektoncd/community/blob/main/adopters.md) list showcases open source projects, vendors and end-users who adopted Tekton. ### Related Projects/Vendors * **Red Hat OpenShift Pipelines** - Red Hat OpenShift Pipelines is a cloud-native, continuous integration and continuous delivery (CI/CD) solution based on Kubernetes resources. It comes bundled with OpenShift and can be installed as an operator. It is a serverless CI/CD system that runs pipelines with all the required dependencies in isolated containers. It is a Tekton fork and uses the standard custom resource definitions (CRDs) for defining CI/CD pipelines that are portable across Kubernetes distributions introduced by Tekton. * **Jenkins** – Jenkins is an open-source automation server widely used for CI/CD. It uses a centralized, plugin-driven architecture and runs jobs on dedicated agents or VMs. Through a Kubernetes plugin it is possible for Jenkins to run and manage agents in a Kubernetes cluster. Jenkins is general-purpose with a large plugin ecosystem but less native Kubernetes alignment. In contrast, Tekton is Kubernetes-native, defines CI/CD pipelines as Kubernetes resources, and is designed for scalable, containerized workflows. * **GitHub Actions** – GitHub Actions is a native CI/CD and automation platform integrated directly into GitHub repositories. It uses workflow files defined as code to automate building, testing and deploying applications. It goes beyond just DevOps and lets you run workflows when other events happen in your repository. For example, you can run a workflow to automatically add the appropriate labels whenever someone creates a new issue in your repository. GitHub Actions operate within the GitHub ecosystem and are not tied to Kubernetes. Tekton is Kubernetes-native and runs pipelines as Kubernetes resources. It can also perform operations on GitHub using the GitHub API and Webhooks so it offers a similar flexibility withou being locked in into the GitHub ecosystem. * **GitLab CI** – GitLab CI/CD is built into GitLab similar to GitHub Actions which are built into GitHub. It allows users to define pipelines using YAML files stored in their GitLab repositories. GitLab CI/CD is tightly integrated with the GitLab platform and manages jobs using its own runners. Tekton is Kubernetes-native and defines pipelines as Kubernetes resources which are executed in containers. It is not tied to a distributed version control system and can be used to automate workflows on GitLab through its API and Webhooks similar to GitHub. * **Argo Workflows** – Argo Workflows is a cloud-native workflow engine for orchestrating parallel jobs and complex workflows as Kubernetes custom resources. Argo Workflows is designed for a general-purpose workflow automation, including CI/CD, data processing and ML workloads. While both Tekton and Argo Workflows provide Kubernetes-native pipeline solutions, Tekton focuses on CI/CD pipelines and standardization. * **Jenkins X** - Jenkins X is an all in one cloud-native CI/CD solution featuring multi-cluster GitOps, Tekton pipelines, secrets management, ChatOps and Preview Environments. It leverages Tekton for a declarative approach to pipelines, managed via GitOps. Jenkins X provides an opinionated, holistic framework using GitOps for software delivery where Tekton is one of its building blocks. Tekton on the other hand offers fine-grained customization of CI/CD pipelines within Kubernetes environments on its own and can be used as part of bigger systems like Jenkins X. * **Flux** - Flux is a GitOps operator that automates the deployment of Kubernetes manifests from a Git repository. It continuously monitors for changes and applies updates to the cluster, ensuring the desired state defined in Git. While Flux excels in managing Kubernetes configuration through GitOps, Tekton focuses on pipeline execution within Kubernetes, providing a framework for integrating, building and deploying applications. Together, they complement each other by using Flux for configuration management and Tekton for CI/CD workflows. * **ArgoCD** - Argo CD is a declarative, GitOps-based continuous delivery tool for Kubernetes. It automates application deployment and lifecycle management by tracking changes in Git repositories. Argo CD manages application states and rollouts, while Tekton provides declarative pipeline definition within Kubernetes or a Git repository and pipeline execution within Kubernetes. Combining Argo CD and Tekton allows teams to manage application deployments effectively with GitOps practices, while executing complex CI/CD workflows through Tekton’s pipelines. * **Knative** - Knative is an open-source platform that extends Kubernetes to provide serverless and event-driven capabilities for cloud-native applications. Tekton was originally developed from Knative’s Build component. As Tekton evolved, it became an independent project and replaced the original Knative Build functionality, becoming the recommended solution for integrating, building and deploying applications in Kubernetes environments using CI/CD pipelines. * **Shipwright** - Shipwright is an extensible framework for building container images on Kubernetes. It supports tools such as Kaniko, Cloud Native Buildpacks, Buildah, and more. It takes advantage of Tekton’s TaskRun and builds upon this foundation with its own concepts and resources. Developers define their build processes using a minimal YAML configuration and execute it with a BuildRun on a Kubernetes cluster. Shipwright adopted from Tekton the fundamental concept of a Task mapping to a Pod and the Steps executed in the context of this Task mapping to separate containers. Shipwright is focused on building images, while Tekton is used to create declarative, cloud-native CI/CD pipelines which are not limited to building.