Tekton is the CI/CD primitive that a surprising number of large Kubernetes shops end up standardizing on, often without a loud announcement. It is Kubernetes-native, every Task and Pipeline is a custom resource, and that design choice quietly makes it both powerful and operationally dangerous. Every TaskRun is a pod with real service account credentials, real workspace mounts, and real network reach. If you treat Tekton like "just another CI tool" and drop it into a cluster with default configuration, you are handing attackers a clean path from a compromised git branch to cluster-admin.
This post is the hardening guide I wish had existed when we first rolled Tekton out across a 400-engineer platform in 2023. It covers the specific configuration knobs that matter, the CVE history that shaped the current defaults, and the operational patterns that keep Tekton from becoming the weakest link in a supply chain. Versions referenced are Tekton Pipelines v0.56 and v0.58, which were the current releases at the time of writing.
Why the default installation is not safe
A fresh Tekton install on Kubernetes 1.29 gives you a controller running in tekton-pipelines with broad RBAC, a default ServiceAccount named default in every namespace that TaskRuns use unless you override it, and no admission policy on what images steps can pull. The Tekton security advisory TEP-0077 from late 2023 and the related CVE-2023-37264 highlighted the core issue: a Task that accepts a user-controlled image parameter can be turned into arbitrary code execution with the permissions of the TaskRun's service account. This is the CI/CD equivalent of eval.
The first thing to do after installing Tekton is to explicitly set the default-service-account feature flag in the feature-flags ConfigMap to something other than default, and create a dedicated low-privilege service account in every namespace where TaskRuns run. A typical starting configuration looks like this:
apiVersion: v1
kind: ConfigMap
metadata:
name: feature-flags
namespace: tekton-pipelines
data:
default-service-account: "tekton-pipeline-sa"
disable-affinity-assistant: "false"
require-git-ssh-secret-known-hosts: "true"
enable-api-fields: "stable"
results-from: "sidecar-logs"
The require-git-ssh-secret-known-hosts flag is the one people miss. Without it, Tekton's git-clone Task will accept any SSH host key, which means a DNS hijack or a compromised git mirror can silently feed malicious code into your pipeline. With it enabled, the TaskRun fails unless a known_hosts entry is present in the auth secret.
Pinning step images
Every Tekton step runs in a container, and the image reference is effectively code. Using floating tags like golang:1.21 or ubuntu:latest in a Task definition means an attacker who compromises the upstream registry account can inject code into every future pipeline run. The fix is mandatory image digest pinning for all steps, enforced at the cluster level.
The cleanest way to do this is a validating admission policy using Kyverno or the Tekton Chains policy controller that rejects any TaskRun or Task with a step image that does not include an @sha256: digest. Tekton Chains v0.20 added native support for attesting step image digests, so you can pair the admission rule with a Chains-generated SLSA provenance attestation that records exactly which image digests ran.
A minimal Kyverno policy for this looks like:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-digest-pinned-tekton-steps
spec:
validationFailureAction: Enforce
rules:
- name: check-step-digest
match:
any:
- resources:
kinds: ["Task", "TaskRun", "Pipeline", "PipelineRun"]
validate:
message: "Tekton step images must be digest-pinned"
pattern:
spec:
=(steps):
- image: "*@sha256:*"
This one policy cuts off the most common Tekton supply-chain attack path. Combine it with a periodic job that resolves the digest for the images you actually want to pin to, commits the updated Task manifests to git, and you have a reproducible, attacker-resistant step image policy.
Workspace secrets and the credential leak problem
Tekton workspaces mount volumes into steps, and this is where credential handling goes wrong most often. A common pattern is to mount a secret into a workspace called registry-credentials so that a buildah or kaniko step can push an image. The problem is that the secret is then readable by every step in the TaskRun, including the step that runs user-controlled build scripts. A malicious package.json with a postinstall hook can read the mounted credentials and exfiltrate them during an npm install step, and the rest of the pipeline will succeed as normal.
The fix is to scope credential workspaces to only the steps that need them, using the onlyWorkspaces field that landed in Tekton v0.55, and to use short-lived credentials wherever the registry supports them. For AWS ECR, this means using IAM Roles for Service Accounts with a TTL of 15 minutes. For Google Artifact Registry, this means Workload Identity with a minimum-scope service account. For Docker Hub or private registries, this means a dedicated robot account with write-only permissions to a specific repository prefix, rotated weekly.
Controlling the Tekton controller itself
The Tekton controller runs as a privileged workload and has a service account that can create pods, read secrets across namespaces where pipelines are configured, and write status to every custom resource. If an attacker can execute code inside the controller pod, they can create arbitrary pods in any pipeline namespace, which is effectively cluster-admin against your CI workloads.
Two things matter here. First, the controller pod should run with a seccomp profile of RuntimeDefault and readOnlyRootFilesystem: true, which the default Helm chart does not enforce but which you should add in your install overlay. Second, network egress from the controller should be restricted to only the Kubernetes API server and the Tekton results service, using a Kubernetes NetworkPolicy. There is no legitimate reason for the controller to make outbound calls to the public internet, and blocking that egress kills a whole class of post-exploitation paths.
Chains and the provenance story
Tekton Chains is the piece most people skip during the initial install, then regret. Chains observes TaskRuns and PipelineRuns and generates signed SLSA v1.0 provenance attestations for the outputs. With the transparency.enabled flag set to true in the Chains config, the signed attestations are uploaded to Sigstore's Rekor transparency log, which means you get a public tamper-evident record of every build your cluster produced. If an attacker modifies a Task in git and re-runs a pipeline, the provenance record will reflect the new Task, and downstream policy enforcement at deploy time can detect the divergence.
Getting Chains working requires a signing key, which for production should live in a KMS. The supported backends are AWS KMS, Google Cloud KMS, Azure Key Vault, and HashiCorp Vault. Storing the signing key as a plain Kubernetes secret is documented as a development-only option and should not appear in production.
How Safeguard Helps
Safeguard ingests Tekton Chains provenance attestations and validates them against your policy gates before allowing deployment, so a pipeline run that lacks a valid signed provenance record or that ran with an unpinned step image is caught before it reaches production. The platform also tracks the step image digests you use across pipelines, alerts when a digest appears in a new CVE feed, and maps each TaskRun's SBOM output to the downstream products that consume it. Combined with policy enforcement on the Tekton service account permissions, Safeguard gives you a continuously verified view of which Tekton pipelines are built to the hardening standards in this guide and which ones are drifting. That matters when you have hundreds of Pipeline definitions and no realistic way to audit them by hand.