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 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 →

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 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 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, 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 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, 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 compliant build systems.

The project mostly relies on Kubernets security features, 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 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 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 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 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.

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

Tekton hosts a "Tekton Friends" repositories where various companies over time shared their interest and use cases with Tekton. Some examples:

  • CloudBees built their DevSecOps platform on top of Tekton
  • Ozone leverages the Tekton framework to provide cloud native Continuous Delivery as-a-service
  • Elastic is using Tekton Pipeline and Tekton CLI in build and release processes for the Elastic Stac
  • Alibaba uses Tekton to continuously deliver services across hybrid clouds

Other companies use Tekton as well (non-exhaustive list):

Finally, the Tekton Adopters list showcases open source projects, vendors and end-users who adopted Tekton.

  • 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.
Last changed by 
 
CDFoundation
CDFoundation
2
520

Read more

CDEvents Working Group Meeting Notes

hackmd-github-sync-badge

Aug 4, 2025
CDEvents Implementation Working Group Meeting Notes

hackmd-github-sync-badge

Jul 28, 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