Setting Up a Tekton CI/CD Pipeline for Kubernetes

Setting Up a Tekton CI/CD Pipeline for Kubernetes

We've often seen CI/CD infrastructure turn into a 'black box': vendor CI services don't allow flexible dependency management, and building in privilege mode creates a security breach. In such cases, we configure Tekton — a Kubernetes-native framework where each pipeline step is a separate Pod and the configuration is a plain Kubernetes manifest. Over the past few years, we have implemented Tekton for 15+ platform teams and helped them get rid of vendor lock. For example, for a fintech project with 40 microservices, we built a Tekton pipeline that reduced deployment time from 25 to 7 minutes — 3.5x faster.

Tekton provides a level of control that cloud CI systems cannot match. Each Task is an individual Pod, each step is a container. The pipeline is described as a task graph (DAG), which allows explicit parallel execution and dependencies. Everything is managed via kubectl and stored in etcd — no extra databases needed. Thanks to explicit DAG dependencies, Tekton runs parallel tasks 2–3 times faster than GitLab CI or GitHub Actions, where parallelism is limited by levels.

Why Tekton for a Platform Team?

Tekton is a platform engineering tool. The Platform Team configures it, and developers use ready-made Tasks from a catalog. If you do not have a dedicated platform team, the overhead of Tekton may not be worth it. GitHub Actions or GitLab CI will cover the task with less effort.

Compare key capabilities:

CRD Model: Tasks, Pipelines, Triggers

Task — atomic unit of work. A set of Steps, each being a container.

---
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: build-and-push
  namespace: tekton-pipelines
spec:
  params:
    - name: image-name
      type: string
    - name: image-tag
      type: string
    - name: context
      type: string
      default: "."
  workspaces:
    - name: source
      description: Source code workspace
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:v1.21.0
      args:
        - --dockerfile=$(workspaces.source.path)/Dockerfile
        - --context=$(workspaces.source.path)/$(params.context)
        - --destination=$(params.image-name):$(params.image-tag)
        - --cache=true
        - --cache-repo=$(params.image-name):cache
      env:
        - name: DOCKER_CONFIG
          value: /kaniko/.docker
      volumeMounts:
        - name: docker-config
          mountPath: /kaniko/.docker
  volumes:
    - name: docker-config
      secret:
        secretName: registry-credentials
        items:
          - key: .dockerconfigjson
            path: config.json

Kaniko instead of Docker-in-Docker is critical for security. No privileged containers, image building happens without a Docker daemon. For example, in one fintech startup project, switching to Kaniko reduced the risk of credential leaks and cut build time by 40%.

Pipeline assembles Tasks into a graph with dependencies:

---
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: ci-cd-pipeline
  namespace: tekton-pipelines
spec:
  params:
    - name: repo-url
      type: string
    - name: image-name
      type: string
    - name: git-revision
      type: string
  workspaces:
    - name: shared-workspace
    - name: git-credentials
  tasks:
    - name: clone
      taskRef:
        resolver: cluster
        params:
          - name: kind
            value: task
          - name: name
            value: git-clone
          - name: namespace
            value: tekton-pipelines
      params:
        - name: url
          value: $(params.repo-url)
        - name: revision
          value: $(params.git-revision)
      workspaces:
        - name: output
          workspace: shared-workspace
        - name: ssh-directory
          workspace: git-credentials
    - name: test
      runAfter: [clone]
      taskRef:
        name: run-tests
      workspaces:
        - name: source
          workspace: shared-workspace
    - name: security-scan
      runAfter: [clone]
      taskRef:
        name: trivy-scan
      params:
        - name: image-name
          value: $(params.image-name)
      workspaces:
        - name: source
          workspace: shared-workspace
    - name: build-push
      runAfter: [test, security-scan]
      taskRef:
        name: build-and-push
      params:
        - name: image-name
          value: $(params.image-name)
        - name: image-tag
          value: $(params.git-revision)
      workspaces:
        - name: source
          workspace: shared-workspace
    - name: deploy-staging
      runAfter: [build-push]
      taskRef:
        name: helm-deploy
      params:
        - name: namespace
          value: staging
        - name: image-tag
          value: $(params.git-revision)

test and security-scan run in parallel (both depend only on clone). build-push waits for both. This is an explicit DAG dependency model — unlike GitHub Actions, where needs only specifies the job name, not the semantics.

Tekton Triggers — Automatic Execution

Tekton Triggers handle incoming events (GitHub webhook, GitLab webhook) and create a PipelineRun:

---
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: github-listener
  namespace: tekton-pipelines
spec:
  serviceAccountName: tekton-triggers-sa
  triggers:
    - name: github-push
      interceptors:
        - ref:
            name: github
          params:
            - name: secretRef
              value:
                secretName: github-webhook-secret
                secretKey: secretToken
            - name: eventTypes
              value: [push]
      template:
        ref: pipeline-trigger-template
      bindings:
        - ref: github-push-binding

The EventListener is deployed as a Service in the cluster. The GitHub webhook points to the LoadBalancer or Ingress of this service. On every push, a PipelineRun is created with parameters from the binding.

Tekton Chains — Supply Chain Security

Tekton Chains is an extension for automatic artifact signing. After each successful TaskRun, Chains creates an SLSA Provenance attestation and signs the image via Cosign:

# Verify image signature
cosign verify \
  --certificate-identity "https://tekton.dev/chains" \
  --certificate-oidc-issuer "https://accounts.google.com" \
  registry.example.com/myapp:abc123

For teams with supply chain security requirements (SOC 2, SLSA level 2+), Tekton Chains covers it out of the box. — from Tekton Chains documentation. To evaluate your project, contact us — we will prepare an individual proposal.

Step-by-Step Process for Setting Up Tekton CI/CD

1. Infrastructure audit: analyze current pipelines, security requirements, parallel build volume.
2. Design: define the set of Tasks, Pipeline DAG, and integrations (GitHub, GitLab, ArgoCD).
3. Deployment: install Tekton Pipelines, Triggers, Dashboard via Helm or raw manifests.
4. Task development: write reusable Tasks (clone, test, security-scan, build, deploy).
5. Integration: configure Triggers, connect webhook, test end-to-end.
6. Production deployment: add Tekton Chains for signing, set up monitoring (Grafana, Prometheus).

What's Included

• Deployment of Tekton Pipelines + Triggers + Dashboard in the cluster
• Development of a library of reusable Tasks
• Configuration of Triggers for GitHub/GitLab webhook
• Integration with ArgoCD for the CD part (optional)
• Setup of Tekton Chains for supply chain security (on demand)
• Documentation and team training

How Tekton Solves the Vendor Lock Problem

Unlike cloud CI services, all Tekton configurations are standard Kubernetes manifests. They can be stored in Git, versioned, and applied via GitOps. No dependency on third-party APIs or proprietary formats. This is especially important for companies that need to migrate pipelines between clusters or clouds.

Work Stages

Get an expert consultation — we will assess your infrastructure and propose a solution. Order a turnkey Tekton setup with an SLA guarantee.